You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/07/10 15:31:49 UTC
SPI/API/Etc.
After writing some testcases for the meta stuff the past couple of days,
something has been bugging me. It's not a major issue, but it does get
into the overloading of terms/accronyms.
It is the use of SPI which in the Java world is commonly associated with
Service Providers Interface to refer to an API which is the Application
Programmer's Interface.
The difference is one of which side of the system we are programming
towards. For example, in JCE we have two sets of APIs. The API designed
for clients to use cryptography is simply called the API. The API designed
for cryptographic algorithm providers is called the SPI. The separation
is only necessary if there is a different API for providers and users.
In our world, the service definitions (i.e. component interfaces and
Avalon Framework) is simply the API. It is the same interface for both
service providers and users alike. There is nothing special to
differentiate them. For the Meta stuff, the users are the containers.
Also, for the meta package we have the API (called meta/spi) and the
"implementation" (called meta/impl). The implementation is not an
implementation of the API. It is a set of writers/builders for component
meta information. If there were some interfaces for defining how to
use the builders and writers in the API library, then the "impl"
package would definitely be an implementation.
So to make a long story short, I would like to have us move toward
standardizing on "API" as the designator for the API specific packages
and not use "SPI" unless it is truly separate from the API. Also, more
specifically, for the Meta package, I would liks us to have the builder
and writer interfaces defined in the API package.
If there is no objection, I will start on that after lunch EST.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
BTW, the SPI stuff has already been moved to API.
> Stephen McConnell wrote:
>
>>
>> Actually I prefer doing the seperation now. When you start managing
>> classloaders the seperation becomes very important and this will have
>> a direct impact on container side extensions. I can take care of it if
>> you like - its just a few minutes effort.
>>
>
> I'm not going to stop you if that is what you mean. I just think it is
> a bit premature at the moment. For example:
>
> * Becaues both containers and tools are clients it might be important to
> have the reader/writer/validator interfaces in the API. Do tools need
> access to the other stuff?
>
> * We only have an incling of an idea what will go into container-side
> extensions. We have three different containers and each of their
> requirements may require something a bit different for the SPI. While
> you may have an idea what is good for Merlin, we need to balance that
> with what is good for Phoenix and Fortress.
>
> * We need to shoot lean and mean, and add to the library as we have need.
>
> I understand your concerns about classloader issues. However, before we
> get to that we should have Container Extensions share the classloader with
> the kernel in the short term so we have a realistic idea on what parts of
> the API are needed for the API/SPI separation.
>
> In other words I prefer taking it one step at a time and letting things
> evolve naturally. We need to focus on getting rudimentary support for
> the API in all three containers, and then beefing it up as we need to.
>
> It will also help the rest of us get our feet wet and become familiar with
> the core API before we inundate you with "Why did you do this?" or
> "Wouldn't
> it be better if we changed that?".
>
> Remember that it is just as much a logistics nightmare to deal with
> hundreds
> of small jars as it is to work with just a few really big ones. Esp. if
> you
> have to remember to update the API jar, the IMPL jar, or just the SPI
> jar and
> the IMPL jar, or just the IMPL jar, or etc., etc.
>
> That said, if you want to create the SPI project now, do it. We can always
> refactor as necessary then.
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Actually I prefer doing the seperation now. When you start managing
> classloaders the seperation becomes very important and this will have a
> direct impact on container side extensions. I can take care of it if you
> like - its just a few minutes effort.
>
I'm not going to stop you if that is what you mean. I just think it is
a bit premature at the moment. For example:
* Becaues both containers and tools are clients it might be important to
have the reader/writer/validator interfaces in the API. Do tools need
access to the other stuff?
* We only have an incling of an idea what will go into container-side
extensions. We have three different containers and each of their
requirements may require something a bit different for the SPI. While
you may have an idea what is good for Merlin, we need to balance that
with what is good for Phoenix and Fortress.
* We need to shoot lean and mean, and add to the library as we have need.
I understand your concerns about classloader issues. However, before we
get to that we should have Container Extensions share the classloader with
the kernel in the short term so we have a realistic idea on what parts of
the API are needed for the API/SPI separation.
In other words I prefer taking it one step at a time and letting things
evolve naturally. We need to focus on getting rudimentary support for
the API in all three containers, and then beefing it up as we need to.
It will also help the rest of us get our feet wet and become familiar with
the core API before we inundate you with "Why did you do this?" or "Wouldn't
it be better if we changed that?".
Remember that it is just as much a logistics nightmare to deal with hundreds
of small jars as it is to work with just a few really big ones. Esp. if you
have to remember to update the API jar, the IMPL jar, or just the SPI jar and
the IMPL jar, or just the IMPL jar, or etc., etc.
That said, if you want to create the SPI project now, do it. We can always
refactor as necessary then.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> With just the meta-info, the number of spi interfaces is rather
>> small. I can imagine the SPI package growing to be more significant
>> with the progressive evolution to include meta-data directives and
>> meta-model interfaces. Given that this is an overhead for container
>> developers and zero impact on users, I would keep the SPI seperate
>> from the API.
>>
>
> How about this:
>
> * Let's start with what we have.
> * Let's start with the .spi subpackage with the interfaces, but no
> separate jar.
> * Let's get that stable and working and at least 90% code coverage.
> * After this point we start fitting the current containers to use the API
> (Fortress/Phoenix at least)
> * When we actually need to beef up the SPI portion, we do that then.
>
> The critical thing at this time is getting the Meta info and using the
> API.
>
> Users of the Meta info API are:
>
> * The Containers
> * The meta-info plugin
> * (Future) Container Extensions
>
> As we get a better feel what is beneficial for Container Extension
> writers,
> we can concentrate on separating the API and SPI. That can only *really*
> happen when we have some extensions written.
>
> Does that sound like a workable plan?
Actually I prefer doing the seperation now. When you start managing
classloaders the seperation becomes very important and this will have a
direct impact on container side extensions. I can take care of it if you
like - its just a few minutes effort.
Steve.
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> With just the meta-info, the number of spi interfaces is rather small.
> I can imagine the SPI package growing to be more significant with the
> progressive evolution to include meta-data directives and meta-model
> interfaces. Given that this is an overhead for container developers and
> zero impact on users, I would keep the SPI seperate from the API.
>
How about this:
* Let's start with what we have.
* Let's start with the .spi subpackage with the interfaces, but no separate jar.
* Let's get that stable and working and at least 90% code coverage.
* After this point we start fitting the current containers to use the API
(Fortress/Phoenix at least)
* When we actually need to beef up the SPI portion, we do that then.
The critical thing at this time is getting the Meta info and using the API.
Users of the Meta info API are:
* The Containers
* The meta-info plugin
* (Future) Container Extensions
As we get a better feel what is beneficial for Container Extension writers,
we can concentrate on separating the API and SPI. That can only *really*
happen when we have some extensions written.
Does that sound like a workable plan?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> In this *special* case, I would be ok with the following
>> structure:
>>
>> meta-api <--- The set of exceptions and serializable
>> descriptors that make up the meta-info
>> layer (currently called meta-spi)
>>
>> meta-spi <--- The set of container-side interfaces
>> that define the system (e.g. builder
>> and writer interfaces) - content is
>> currently mixed under the impl
>> package.
>>
>> meta-impl <-- The implementation of the SPI (as as
>> with the removal of the builder and
>> writer interfaces).
>>
>> Cheers, Steve.
>
>
> :) I really hope we aren't going to have as many different
> ways of persisting the meta info as there are containers.
>
> That said, we may change how we persist the information later.
> This separation just may come in handy in that case--esp. when
> we want to test our compatibility layers.
>
> Another question:
>
> In most Java APIs where there is both the client and service
> provider (like JCE) the separation was done at the Java package
> level. For example:
>
> org.apache.avalon.meta --> typical API
> org.apache.avalon.meta.spi --> SPI specific classes
>
> This is the way JCE and JNDI are both organised. All users
> of the software are provided with the API and SPI all in the
> same distributable.
>
> Should we mimic this approach?
>
> It seems of little value to me to have the SPI in a separate
> JAR, although of great value to be able to plug in implementations
> (so that Fortress can work with its older version of the meta
> persistence).
With just the meta-info, the number of spi interfaces is rather small.
I can imagine the SPI package growing to be more significant with the
progressive evolution to include meta-data directives and meta-model
interfaces. Given that this is an overhead for container developers and
zero impact on users, I would keep the SPI seperate from the API.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> In this *special* case, I would be ok with the following
> structure:
>
> meta-api <--- The set of exceptions and serializable
> descriptors that make up the meta-info
> layer (currently called meta-spi)
>
> meta-spi <--- The set of container-side interfaces
> that define the system (e.g. builder
> and writer interfaces) - content is
> currently mixed under the impl
> package.
>
> meta-impl <-- The implementation of the SPI (as as
> with the removal of the builder and
> writer interfaces).
>
> Cheers, Steve.
:) I really hope we aren't going to have as many different
ways of persisting the meta info as there are containers.
That said, we may change how we persist the information later.
This separation just may come in handy in that case--esp. when
we want to test our compatibility layers.
Another question:
In most Java APIs where there is both the client and service
provider (like JCE) the separation was done at the Java package
level. For example:
org.apache.avalon.meta --> typical API
org.apache.avalon.meta.spi --> SPI specific classes
This is the way JCE and JNDI are both organised. All users
of the software are provided with the API and SPI all in the
same distributable.
Should we mimic this approach?
It seems of little value to me to have the SPI in a separate
JAR, although of great value to be able to plug in implementations
(so that Fortress can work with its older version of the meta
persistence).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: SPI/API/Etc.
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> After writing some testcases for the meta stuff the past couple of days,
> something has been bugging me. It's not a major issue, but it does get
> into the overloading of terms/accronyms.
>
> It is the use of SPI which in the Java world is commonly associated with
> Service Providers Interface to refer to an API which is the Application
> Programmer's Interface.
>
> The difference is one of which side of the system we are programming
> towards. For example, in JCE we have two sets of APIs. The API designed
> for clients to use cryptography is simply called the API. The API
> designed
> for cryptographic algorithm providers is called the SPI. The separation
> is only necessary if there is a different API for providers and users.
>
> In our world, the service definitions (i.e. component interfaces and
> Avalon Framework) is simply the API. It is the same interface for both
> service providers and users alike. There is nothing special to
> differentiate them. For the Meta stuff, the users are the containers.
>
> Also, for the meta package we have the API (called meta/spi) and the
> "implementation" (called meta/impl). The implementation is not an
> implementation of the API. It is a set of writers/builders for component
> meta information. If there were some interfaces for defining how to
> use the builders and writers in the API library, then the "impl"
> package would definitely be an implementation.
>
> So to make a long story short, I would like to have us move toward
> standardizing on "API" as the designator for the API specific packages
> and not use "SPI" unless it is truly separate from the API. Also, more
> specifically, for the Meta package, I would liks us to have the builder
> and writer interfaces defined in the API package.
>
> If there is no objection, I will start on that after lunch EST.
In this *special* case, I would be ok with the following
structure:
meta-api <--- The set of exceptions and serializable
descriptors that make up the meta-info
layer (currently called meta-spi)
meta-spi <--- The set of container-side interfaces
that define the system (e.g. builder
and writer interfaces) - content is
currently mixed under the impl
package.
meta-impl <-- The implementation of the SPI (as as
with the removal of the builder and
writer interfaces).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org