API proposal

[Pid <pi...@pidster.com>]

Hi,

I've committed a proposal for the API spec, it aims to simplify the
interaction with the library and focuses on configuration and setup.

There are a couple of things to consider in the light of recent
discussion, which I don't have proposals for as yet, namely:

 1. configurable storage of some sort

 2. the possible need to separate client & server factories

 3. the server interface methods are not defined


Please critique/discuss.


p

Re: API proposal

[Simone Tripodi <si...@gmail.com>]

Hi Pid,
maybe we're finding a common way :) I'd suggest Java6 too for many
reasons, mainly:

* the ServiceLoader;
* the APT invoked automatically by javac (do you remember the OAuth
Annotations we discussed in the previous thread? we could generate
with APT the OAuth messages/tokens marshallers/unmarshallers
automatically using APT... no? :P)
* the built-in JAXB APIs;

let's call a vote for the Java version, I started feeling the same
wish to see progress faster :P

BTW... C O N G R A U L A T I O N S for your first Pid Junior, that's
amazing news!!! I wish you all, all the best wishes!!!
Let's keep in touch :)

Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Jun 22, 2010 at 4:58 PM, Pid <pi...@pidster.com> wrote:
> On 22/06/2010 14:59, Simone Tripodi wrote:
>> Hello Pid,
>> sorry if I'm late but at the same time I'm thinking about Amber stuff,
>> there's a customer that complains for his stuff :P:P
>> Follow my comments below:
>>
>>>
>>> Not at all.  I stated early on (if not in this thread, the other one)
>>> that my suggestion for the spec was interfaces and a single class which
>>> contained code.  A specification can be more complex than just a few
>>> interfaces: we can also define rules for how things work.
>>>
>>
>> Sure, that's why I'm strongly convinced some defined interfaces, like
>> Token entities or OAuth messages, can definitively become final POJOs
>> in our API layer.
>
> Agreed.
>
>>> I'm confused as to why this is now a problem.
>>>
>>
>> Not really a problem, and sorry if I gave you that impression, but
>> once again Id' like to express my concern about separating the minimal
>> implementation to the aux features, the question is which implies at
>> coding level moving the XML stuff from the spec to a proper Amber
>> specification.
>>
>> Just to give you an idea: an old OAuth demo we realized 1 year ago[1]
>> (video is in Italian only, sorry:( ) was demonstrating an OAuth
>> desktop application that for instantiate the consumer it reads the
>> exposed Service Provider descriptor from the discovery XML. That's yet
>> another way to instantiate what we need, that not necessary has to be
>> included in the spec layer.
>>
>> Moreover, the actual XML layer involves also decisions have to be
>> taken, like for example: which Java version should we support? 1.5 I'd
>> say, where JAXB is not included in the JVM so the spec APIs have to
>> bring with themselves the JAXB dependencies... even if my heart would
>> suggest to switch to Java6... at the end of the day, I wouldn't avoid
>> define an API layer that depends to a specific implementation. BTW, if
>> the majority of the committers - that I hope start participating a
>> little more actively - agree to keep the JAXB in the Spec, I won't
>> oppose any objection.
>
> Yes, fair enough.  If we target 1.5 then I'll work out a way to make
> JAXB optional & move it to a separate package.
>
> I'd like to see 1.6 as our target by preference, for more reasons than JAXB.
>
>>>> Of course I'd like too someone
>>>> else participate in this discussion, but not just binding votes but
>>>> rather expressing their ideas, their vision, their suggestions
>>>> first!!! Then we'll find our way.
>>>
>>> Me too.  :)
>>> I enjoy a robust discussion, but I'd like to make some progress too.
>>>
>>
>> I was think about an idea: where are you located? London? It could be
>> nice to organize, even unofficial, an Amber Get-Together to discuss
>> face to face the final startup... WDYT?
>
> Yep.  We'd probably get a lot done quickly.
>
> I was thinking about emailing the 'interested parties' and the OAuth WG
> list & letting them know we're here to build up participation.
>
> I'd happily head out to Italy (I'm rather partial to a nice Barolo), but
> we're is expecting our first baby in a few weeks & I don't think Mrs Pid
> would forgive me... :)
>
>
>>> I only know your ideas from the code you've committed - which looks like
>>> it's designed around the core requirement for a signature.
>>>
>>> I really believe the two things are compatible and can be joined together.
>>
>> sure, that's what I've been working on since yesterday; I started the
>> Amber lab when my previous company stopped paying me to realize, with
>> my former collegues, an old OAuth 1.0 implementation[2], which still
>> has useful hints: for example, for what I can read from the javadoc,
>> the actual API layer doesn't take care that the oauth consumer could
>> be a desktop application, in the past I solved that problem in a
>> simple way[3] (the description is very very easy).
>>
>> I'm looking forward to have more clear ideas!!! Thanks for your time
>> and dedication!
>
> Cool.
>
> I'll have a read of the links below tonight.
>
>
> p
>
>
>
>> [1] http://www.bettersoftware.it/conference/talks/openstack-leggero-aperto-basato-sul-web
>> [2] http://code.google.com/p/asmx-oauth
>> [3] http://asmx-oauth.googlecode.com/svn/site/1.0/core/consumer/authenticating.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>
>
>

Re: API proposal

[Pid <pi...@pidster.com>]

On 22/06/2010 14:59, Simone Tripodi wrote:
> Hello Pid,
> sorry if I'm late but at the same time I'm thinking about Amber stuff,
> there's a customer that complains for his stuff :P:P
> Follow my comments below:
> 
>>
>> Not at all.  I stated early on (if not in this thread, the other one)
>> that my suggestion for the spec was interfaces and a single class which
>> contained code.  A specification can be more complex than just a few
>> interfaces: we can also define rules for how things work.
>>
> 
> Sure, that's why I'm strongly convinced some defined interfaces, like
> Token entities or OAuth messages, can definitively become final POJOs
> in our API layer.

Agreed.

>> I'm confused as to why this is now a problem.
>>
> 
> Not really a problem, and sorry if I gave you that impression, but
> once again Id' like to express my concern about separating the minimal
> implementation to the aux features, the question is which implies at
> coding level moving the XML stuff from the spec to a proper Amber
> specification.
> 
> Just to give you an idea: an old OAuth demo we realized 1 year ago[1]
> (video is in Italian only, sorry:( ) was demonstrating an OAuth
> desktop application that for instantiate the consumer it reads the
> exposed Service Provider descriptor from the discovery XML. That's yet
> another way to instantiate what we need, that not necessary has to be
> included in the spec layer.
> 
> Moreover, the actual XML layer involves also decisions have to be
> taken, like for example: which Java version should we support? 1.5 I'd
> say, where JAXB is not included in the JVM so the spec APIs have to
> bring with themselves the JAXB dependencies... even if my heart would
> suggest to switch to Java6... at the end of the day, I wouldn't avoid
> define an API layer that depends to a specific implementation. BTW, if
> the majority of the committers - that I hope start participating a
> little more actively - agree to keep the JAXB in the Spec, I won't
> oppose any objection.

Yes, fair enough.  If we target 1.5 then I'll work out a way to make
JAXB optional & move it to a separate package.

I'd like to see 1.6 as our target by preference, for more reasons than JAXB.

>>> Of course I'd like too someone
>>> else participate in this discussion, but not just binding votes but
>>> rather expressing their ideas, their vision, their suggestions
>>> first!!! Then we'll find our way.
>>
>> Me too.  :)
>> I enjoy a robust discussion, but I'd like to make some progress too.
>>
> 
> I was think about an idea: where are you located? London? It could be
> nice to organize, even unofficial, an Amber Get-Together to discuss
> face to face the final startup... WDYT?

Yep.  We'd probably get a lot done quickly.

I was thinking about emailing the 'interested parties' and the OAuth WG
list & letting them know we're here to build up participation.

I'd happily head out to Italy (I'm rather partial to a nice Barolo), but
we're is expecting our first baby in a few weeks & I don't think Mrs Pid
would forgive me... :)


>> I only know your ideas from the code you've committed - which looks like
>> it's designed around the core requirement for a signature.
>>
>> I really believe the two things are compatible and can be joined together.
> 
> sure, that's what I've been working on since yesterday; I started the
> Amber lab when my previous company stopped paying me to realize, with
> my former collegues, an old OAuth 1.0 implementation[2], which still
> has useful hints: for example, for what I can read from the javadoc,
> the actual API layer doesn't take care that the oauth consumer could
> be a desktop application, in the past I solved that problem in a
> simple way[3] (the description is very very easy).
>
> I'm looking forward to have more clear ideas!!! Thanks for your time
> and dedication!

Cool.

I'll have a read of the links below tonight.


p



> [1] http://www.bettersoftware.it/conference/talks/openstack-leggero-aperto-basato-sul-web
> [2] http://code.google.com/p/asmx-oauth
> [3] http://asmx-oauth.googlecode.com/svn/site/1.0/core/consumer/authenticating.html
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/

Re: API proposal

[Simone Tripodi <si...@gmail.com>]

Hello Pid,
sorry if I'm late but at the same time I'm thinking about Amber stuff,
there's a customer that complains for his stuff :P:P
Follow my comments below:

>
> Not at all.  I stated early on (if not in this thread, the other one)
> that my suggestion for the spec was interfaces and a single class which
> contained code.  A specification can be more complex than just a few
> interfaces: we can also define rules for how things work.
>

Sure, that's why I'm strongly convinced some defined interfaces, like
Token entities or OAuth messages, can definitively become final POJOs
in our API layer.

>
> I'm confused as to why this is now a problem.
>

Not really a problem, and sorry if I gave you that impression, but
once again Id' like to express my concern about separating the minimal
implementation to the aux features, the question is which implies at
coding level moving the XML stuff from the spec to a proper Amber
specification.

Just to give you an idea: an old OAuth demo we realized 1 year ago[1]
(video is in Italian only, sorry:( ) was demonstrating an OAuth
desktop application that for instantiate the consumer it reads the
exposed Service Provider descriptor from the discovery XML. That's yet
another way to instantiate what we need, that not necessary has to be
included in the spec layer.

Moreover, the actual XML layer involves also decisions have to be
taken, like for example: which Java version should we support? 1.5 I'd
say, where JAXB is not included in the JVM so the spec APIs have to
bring with themselves the JAXB dependencies... even if my heart would
suggest to switch to Java6... at the end of the day, I wouldn't avoid
define an API layer that depends to a specific implementation. BTW, if
the majority of the committers - that I hope start participating a
little more actively - agree to keep the JAXB in the Spec, I won't
oppose any objection.

>> Of course I'd like too someone
>> else participate in this discussion, but not just binding votes but
>> rather expressing their ideas, their vision, their suggestions
>> first!!! Then we'll find our way.
>
> Me too.  :)
> I enjoy a robust discussion, but I'd like to make some progress too.
>

I was think about an idea: where are you located? London? It could be
nice to organize, even unofficial, an Amber Get-Together to discuss
face to face the final startup... WDYT?

>
> I only know your ideas from the code you've committed - which looks like
> it's designed around the core requirement for a signature.
>
> I really believe the two things are compatible and can be joined together.

sure, that's what I've been working on since yesterday; I started the
Amber lab when my previous company stopped paying me to realize, with
my former collegues, an old OAuth 1.0 implementation[2], which still
has useful hints: for example, for what I can read from the javadoc,
the actual API layer doesn't take care that the oauth consumer could
be a desktop application, in the past I solved that problem in a
simple way[3] (the description is very very easy).

I'm looking forward to have more clear ideas!!! Thanks for your time
and dedication!
all the best,
Simo

[1] http://www.bettersoftware.it/conference/talks/openstack-leggero-aperto-basato-sul-web
[2] http://code.google.com/p/asmx-oauth
[3] http://asmx-oauth.googlecode.com/svn/site/1.0/core/consumer/authenticating.html

http://people.apache.org/~simonetripodi/
http://www.99soft.org/

Re: API proposal

[Pid <pi...@pidster.com>]

On 18/06/2010 20:01, Simone Tripodi wrote:
> "feature of the spec API" sounds to me a little against what we
> discussed in the previous thread of 16 messages :P

Not at all.  I stated early on (if not in this thread, the other one)
that my suggestion for the spec was interfaces and a single class which
contained code.  A specification can be more complex than just a few
interfaces: we can also define rules for how things work.


> We all agreed in having a "pure OAuth spec" module, even at the
> beginning I wasn't totally convinced, but well, it makes a lot of
> sense and we've been discussing with the shared intent to have it -
> and I hope we'll start making it ASAP.

Separating the abstract from the concrete is a good idea.  We should
avoid having to write code against a mixture of our interfaces and
implementation classes.


From the Amber Proposal:

"The API specification will be provided as a separate JAR file allowing
re-use by other developers and permits configuration:

- by XML
- by the Java JAR Services "ServiceLoader" mechanism
- programmatically

The API component specifies that an implementation must provide default
classes for Provider, Consumer and Token objects making Amber easy to
integrate with existing infrastructure and OAuth client interactions
possible with virtually no additional configuration. The API is flexible
enough to allow programmatic customisation or replacement of much of the
implementation, including the default HTTP transport.
"

I'm confused as to why this is now a problem.


> Of course I'd like too someone
> else participate in this discussion, but not just binding votes but
> rather expressing their ideas, their vision, their suggestions
> first!!! Then we'll find our way.

Me too.  :)
I enjoy a robust discussion, but I'd like to make some progress too.


> At that stage, for what I can see, we're still far to call any vote.
> Maybe we should start changing approach and thinking about how to
> merge ideas, rather then try to explain what's the better one.

I only know your ideas from the code you've committed - which looks like
it's designed around the core requirement for a signature.

I really believe the two things are compatible and can be joined together.


> BTW, can you explain me what could imply moving the XML stuff in an
> hypothetical "amber-impl" module?

The major benefit of doing local configuration in the o.a.amber.OAuth
class is that a user would be able to swap an implementation .jar
without having to change & recompile code.


The XML stuff is a few lines of code in one method, in one class, in the
only class in the spec that actually has code - and it's only used for
discovery of local config.

All of the rest is/would be in the implementation and is mostly a case
of making some beans with the right JAXB annotations.


> Tomorrow I'll have more spare time to read your javadoc, I'll have a
> deep look to your stuff. I'd like if you could do the same with the
> original codebase.

I've spent a lot of time looking at it in the last week.


> Thanks in advance, have a nice weekend,

And you.  :)


p


> Simo
> 
>>>
>>> It is, since the XML stuff is part of the amber implementation and not
>>> for the specification API.
>>
>> I think we can make it a feature of the spec API that certain methods of
>> configuration are 'required' - and that the o.a.amber.OAuth class
>> performs config & implementation discovery.
>>
>> But as we disagree, maybe you could make a proposal for what the entry
>> point(s) should be instead and we could have a vote or something?
>>
>>
>> p
>>
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/

Re: API proposal

[Simone Tripodi <si...@gmail.com>]

"feature of the spec API" sounds to me a little against what we
discussed in the previous thread of 16 messages :P

We all agreed in having a "pure OAuth spec" module, even at the
beginning I wasn't totally convinced, but well, it makes a lot of
sense and we've been discussing with the shared intent to have it -
and I hope we'll start making it ASAP. Of course I'd like too someone
else participate in this discussion, but not just binding votes but
rather expressing their ideas, their vision, their suggestions
first!!! Then we'll find our way.

At that stage, for what I can see, we're still far to call any vote.
Maybe we should start changing approach and thinking about how to
merge ideas, rather then try to explain what's the better one.

BTW, can you explain me what could imply moving the XML stuff in an
hypothetical "amber-impl" module?

Tomorrow I'll have more spare time to read your javadoc, I'll have a
deep look to your stuff. I'd like if you could do the same with the
original codebase.
Thanks in advance, have a nice weekend,
Simo

>>
>> It is, since the XML stuff is part of the amber implementation and not
>> for the specification API.
>
> I think we can make it a feature of the spec API that certain methods of
> configuration are 'required' - and that the o.a.amber.OAuth class
> performs config & implementation discovery.
>
> But as we disagree, maybe you could make a proposal for what the entry
> point(s) should be instead and we could have a vote or something?
>
>
> p
>

http://people.apache.org/~simonetripodi/
http://www.99soft.org/

Re: API proposal

[Pid <pi...@apache.org>]

On 18/06/2010 15:53, Simone Tripodi wrote:
> Hi,
> 
>>
>> There's only one interface each for Client and Server, all other
>> interfaces have shared use in both client & server.  Are you suggesting
>> we move them to:
>>
>>  o.a.amber.client.OAuthClient
>>  o.a.amber.server.OAuthServer
>>
>> ?
> 
> Yes, I'm sure both client/server will need of course of aux components
> that could be included in our "standardization" process.
> 
>>
>> I don't think this is necessary.  It only exists in the o.a.amber.OAuth
>> class and it's for entirely local pre-use configuration.  It's not an
>> alternative to OAuth Discovery.
>>
>> It maps XML configuration files to the OAuthConsumer & OAuthProvider
>> interfaces via JAXB and provides the discovered data to the factory
>> object.  The implementation only need to specify where to find the
>> concrete classes which implement these interfaces & JAXB does the rest
>> it's very efficient and makes it super easy for a developer to use the
>> library, by dropping some XML in the proper location.
>>
>> It meets our stated goal of providing multiple configuration methods.
>>
> 
> It is, since the XML stuff is part of the amber implementation and not
> for the specification API.

I think we can make it a feature of the spec API that certain methods of
configuration are 'required' - and that the o.a.amber.OAuth class
performs config & implementation discovery.

But as we disagree, maybe you could make a proposal for what the entry
point(s) should be instead and we could have a vote or something?


p

>>> * just write 2 lines on the ML about how the interfaces interact with
>>> each other, something simple like I did in a previous email.
>>
>> 2 lines might be tricky!
>>
>> The o.a.amber.OAuth class is the only one with code and it's just for
>> processing the different methods of configuration, discovering
>> implementations, then configuring a factory object which can create a
>> client or a server.
>>
>> OAuthClient has plenty of JavaDoc.
>>
>> OAuthServer isn't defined yet, but I have some ideas.
>>
>>
>> p
>>
> 
> Ok thanks, I'll have to generate the javadoc so...
> 
> Have a nice weekend,
> Simo
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/

Re: API proposal

[Simone Tripodi <si...@gmail.com>]

Hi,

>
> There's only one interface each for Client and Server, all other
> interfaces have shared use in both client & server.  Are you suggesting
> we move them to:
>
>  o.a.amber.client.OAuthClient
>  o.a.amber.server.OAuthServer
>
> ?

Yes, I'm sure both client/server will need of course of aux components
that could be included in our "standardization" process.

>
> I don't think this is necessary.  It only exists in the o.a.amber.OAuth
> class and it's for entirely local pre-use configuration.  It's not an
> alternative to OAuth Discovery.
>
> It maps XML configuration files to the OAuthConsumer & OAuthProvider
> interfaces via JAXB and provides the discovered data to the factory
> object.  The implementation only need to specify where to find the
> concrete classes which implement these interfaces & JAXB does the rest
> it's very efficient and makes it super easy for a developer to use the
> library, by dropping some XML in the proper location.
>
> It meets our stated goal of providing multiple configuration methods.
>

It is, since the XML stuff is part of the amber implementation and not
for the specification API.

>
>> * just write 2 lines on the ML about how the interfaces interact with
>> each other, something simple like I did in a previous email.
>
> 2 lines might be tricky!
>
> The o.a.amber.OAuth class is the only one with code and it's just for
> processing the different methods of configuration, discovering
> implementations, then configuring a factory object which can create a
> client or a server.
>
> OAuthClient has plenty of JavaDoc.
>
> OAuthServer isn't defined yet, but I have some ideas.
>
>
> p
>

Ok thanks, I'll have to generate the javadoc so...

Have a nice weekend,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/

Re: API proposal

[Pid <pi...@apache.org>]

On 18/06/2010 10:25, Simone Tripodi wrote:
> Hi Pid,
> I did just minor reviews to your proposal (maven and svn stuff only)
> and I'd really appreciate if you could, before starting discussing
> about/modifying something:
> 
> * move to proper 'client' package client-only related stuff (it would
> much more clear and easier for me add the server API);

There's only one interface each for Client and Server, all other
interfaces have shared use in both client & server.  Are you suggesting
we move them to:

 o.a.amber.client.OAuthClient
 o.a.amber.server.OAuthServer

?


> * move your custom XML stuff to a dedicated module, since is not
> contained in the spec and doesn't match neither with OAuth Discovery
> 1.0;

I don't think this is necessary.  It only exists in the o.a.amber.OAuth
class and it's for entirely local pre-use configuration.  It's not an
alternative to OAuth Discovery.

It maps XML configuration files to the OAuthConsumer & OAuthProvider
interfaces via JAXB and provides the discovered data to the factory
object.  The implementation only need to specify where to find the
concrete classes which implement these interfaces & JAXB does the rest
it's very efficient and makes it super easy for a developer to use the
library, by dropping some XML in the proper location.

It meets our stated goal of providing multiple configuration methods.


> * just write 2 lines on the ML about how the interfaces interact with
> each other, something simple like I did in a previous email.

2 lines might be tricky!

The o.a.amber.OAuth class is the only one with code and it's just for
processing the different methods of configuration, discovering
implementations, then configuring a factory object which can create a
client or a server.

OAuthClient has plenty of JavaDoc.

OAuthServer isn't defined yet, but I have some ideas.


p



> Many thanks in advance, have a nice day!
> Simo
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
> 
> 
> 
> On Thu, Jun 17, 2010 at 2:51 PM, Simone Tripodi
> <si...@gmail.com> wrote:
>> Hi Pid,
>> seen the commit, thanks, just give me the time to digest it :P I have
>> proposals for storages, already experienced in the past and part of it
>> is already contained in the existing code.
>> Chat later,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Jun 17, 2010 at 2:29 PM, Pid <pi...@pidster.com> wrote:
>>> Hi,
>>>
>>> I've committed a proposal for the API spec, it aims to simplify the
>>> interaction with the library and focuses on configuration and setup.
>>>
>>> There are a couple of things to consider in the light of recent
>>> discussion, which I don't have proposals for as yet, namely:
>>>
>>>  1. configurable storage of some sort
>>>
>>>  2. the possible need to separate client & server factories
>>>
>>>  3. the server interface methods are not defined
>>>
>>>
>>> Please critique/discuss.
>>>
>>>
>>> p
>>>
>>>
>>

Re: API proposal

[Simone Tripodi <si...@gmail.com>]

Hi Pid,
I did just minor reviews to your proposal (maven and svn stuff only)
and I'd really appreciate if you could, before starting discussing
about/modifying something:

* move to proper 'client' package client-only related stuff (it would
much more clear and easier for me add the server API);
* move your custom XML stuff to a dedicated module, since is not
contained in the spec and doesn't match neither with OAuth Discovery
1.0;
* just write 2 lines on the ML about how the interfaces interact with
each other, something simple like I did in a previous email.

Many thanks in advance, have a nice day!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Jun 17, 2010 at 2:51 PM, Simone Tripodi
<si...@gmail.com> wrote:
> Hi Pid,
> seen the commit, thanks, just give me the time to digest it :P I have
> proposals for storages, already experienced in the past and part of it
> is already contained in the existing code.
> Chat later,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Thu, Jun 17, 2010 at 2:29 PM, Pid <pi...@pidster.com> wrote:
>> Hi,
>>
>> I've committed a proposal for the API spec, it aims to simplify the
>> interaction with the library and focuses on configuration and setup.
>>
>> There are a couple of things to consider in the light of recent
>> discussion, which I don't have proposals for as yet, namely:
>>
>>  1. configurable storage of some sort
>>
>>  2. the possible need to separate client & server factories
>>
>>  3. the server interface methods are not defined
>>
>>
>> Please critique/discuss.
>>
>>
>> p
>>
>>
>

Re: API proposal

[Simone Tripodi <si...@gmail.com>]

Hi Pid,
seen the commit, thanks, just give me the time to digest it :P I have
proposals for storages, already experienced in the past and part of it
is already contained in the existing code.
Chat later,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, Jun 17, 2010 at 2:29 PM, Pid <pi...@pidster.com> wrote:
> Hi,
>
> I've committed a proposal for the API spec, it aims to simplify the
> interaction with the library and focuses on configuration and setup.
>
> There are a couple of things to consider in the light of recent
> discussion, which I don't have proposals for as yet, namely:
>
>  1. configurable storage of some sort
>
>  2. the possible need to separate client & server factories
>
>  3. the server interface methods are not defined
>
>
> Please critique/discuss.
>
>
> p
>
>