Re: Sketch of updated APIs (was Re: Redirection and creation)

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 20 Apr 2007 12:35:59 +0200

Jerome Louvel wrote:
> Hi Paul,
>>> (i) For the performance, I'm sure there would be ways to
>> optimize the
>>> introspection if necessary to not have to do it for each
>> call for example.
>> It can. Although to get really good performance requires some rather
>> sophisticated stuff with byte code generation, like what JAXB 2.x RI
>> does, and it is not easy. The Java type system is there for a
>> reason :-)
> I'm sure JAXB implementation is pretty complex!

Anything that has the unfortunate association with the W3C XML Schema
beast is :-)

> I hope we won't have to go
> as far (byte code generation) initially :)

If we use annotations at the granular level then i suspect us
implementors will have to do something eventually because the reflection
code for accessing getters will likely be hot spots. I am not saying
that is an excuse for not using annotations but at least to me it
stresses more on the use-cases to warrant such implementation complexity.

>> The style used by BlinkSale is very similar to APP (namely CRUD of
>> collections/items) and infact the Atom format is an option at
>> least for
>> getting Invoices. So in this case i would say it is likely that
>> ROME/Atom would be used.
> I agree, the Atom format is a useful type of representation. For the APP
> support, let's consider it right after Blinksale API, as a more advanced
> case.

OK. As i understand it the API only allows one to get atom entries/feeds.

>> Once you have done invoice and invoices the pattern sort of
>> repeats for
>> deliveries/delivery and payments/payment. Below [2] is a
>> really rough,
>> back of the envelope sketch for Invoices and Invoice resources.
> <snip>Blinksale example</snip>
> Thanks for sharing this code sample Paul. It's interesting because it really
> helps me understand the different ways we approach the same design problem.

Thanks. I may try to expand out the impl to include all the resources.
You may find that looking at Stapler/Hudson is also useful to see how we
approached things.

> I'll try to post my version early next week.

Looking forward to it.

> We are definitely converging
> even if their remain some notable differences.

I think we are making progress. Your emails on life-cycles focused me to
think about per-request, which makes it much easier to keep things DRY
for getting/checking stuff (e.g. whether an invoice id exists or not).
But we have not touched on the approach to sub/child resources yet :-)


| ? + ? = To question
    Paul Sandoz