Aaron Anderson wrote:
> Hmm, I registered for the user message digest but I guess that is a
> different list.
>
It is.
> Thanks for the response. It makes perfect sense that the WebApplication
> would need a have a definitive list of resource classes when it
> initializes. Using the list of resource classes it can introspect them,
> discover the list of URI templates, and define optimize routing rules
> for requests to the resource instances.
>
>
>
> I think what I will do now is that each time a new ResourceClass needs
> to be added to or removed from an existing WebApplication I will simply
> discard the existing WebApplication and create a new one with the proper
> resource instances and classes. At first I was concerned about doing
> this because I was concerned about losing state information and at the
> surface it seems inefficient. On second thought REST services are by
> definition stateless and the act of recreating a new WebResolver would
> not entail that much overhead if I use a copy constructor. I’ll try this
> approach and inform the list on how it works out.
>
You are right about the application state, one should avoid using a
session ID and/or cookies as a reference to store application state on
the server, and such application state should be embodied in the
representations.
However, although i think the 'workaround' you have proposed will work
it seems a rather brute force and rather slow approach that requires you
to do more work.
I think you have identified a use-case lacking in the current SPI. It is
actually not that tricky to implement (the synchronization logic is the
most tricky bit, all other functionality is mostly in place). So i would
like to implement this, although i doubt i will have time to do this
until Aug as i am on holiday (inclusive) from 20th to the 27th.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109