Hi Grek,
you asked us to give our two cents so after a day of reading your long,
long text I'll try to ;-)
I'll surely have to re-read it but here are some thoughts:
> I promised to give an overview on our Servlet Service Framework, its
> status and relation to the
> Resource-Oriented Architecture (ROA) and RESTful design principles.
> It's my first [RT] mail so I kindly ask you to be gentle when you
> appraise.
>
> Servlet Service Fw keeps Virtual Sitemap/Pipeline Components promise
> --------------------------------------------------------------------
>
> Current implementation has few limitations:
> * SAX events are serialized and parsed again when making POST
> request to the servlet service
> * caching is not supported at any mean
> * environmental data (request, session, flowscript context aka
> bizData) of caller is not
> available in the called service
Sounds cool, but doesn't this result in a scenario like this?:
- browser calls resource A
- resource A runs through a pipeline calling resource B
- resource A is a SAX-pipeline, serializes SAX-events to POST-parameters
for calling B
- resource B deserializes parameters, feeds its own pipeline with
SAX-events, serializes results to HTTP-like result, feeds it back to
resource B
Seems we have a loss in performance and increase in memory needs.
> Attaining ROA nirvana with Cocoon
> -------------------------------------
>
> -- Sitemap --
> It's old but still powerful component in Cocoon. As long as we deal
> with URIs sitemap's matching mechanisms will be relevant. Take a look
> at quotation from RWS book, "When In Doubt, Make It a Resource"
> sub-chapter:
> You probably guessed it, routes.rb file acts as simple dispatcher that
> dispatches requests to the controller. Quite the same could be
> achieved with our sitemap engine:
>
> <map:sitemap>
> <map:pipeline>
>
> <map:match pattern="/v1/users/*/bookmarks/*">
> <map:call
> function="bookmarksController_handle{$cocoon/request/method}">
> <map:parameter name="username" value="{1}"/>
> <map:parameter name="bookmark" value="{2}"/>
> </map:call>
> </map:match>
>
> <map:match pattern="/v1/users/*">
> <map:call
> function="usersController_handle{$cocoon/request/method}">
> <map:parameter name="username" value="{1}"/>
> </map:call>
> </map:match>
>
> </map:pipeline>
> </map:sitemap>
>
> This code could be done much compact by coming up with conventions but
> it's topic for another discussion, really.
I'm not sure if I fully catch on your example. Can you explain it a
little bit more (as your eMail was addresses to the users list I bet I'm
not the only one) ?
What about handling the matching of non-URIs e.g. headers?
I'm doubtful about conventions. IMO they should be only that -
conventions - and not mandatory. For example a URL visible from external
clients should not always represent the internal structure.
> -- Flowscript --
> When approaching ROA design we need to throw out continuations of
> course. So what's the use of flowscript, then?
>
> It's my very own opinion but I think that our controllers should be
> sitemap(as dispatcher)+script(containing actual controller's code). I
> think that most of us would agree that dynamic languages have some
> features really useful for fast prototyping and glueing code.
>
> I take role of flowscript and pipelines (below) really briefly because
> it's quite far from big picture of Servlet Service Framework. :-)
Please explain how you want to replace continuations and flowscript. One
of the reasons why I prefer Cocoon are continuations! The extensive use
of flowscript spread on myriads of files isn't great, though, but for
controlling a flow (!) with reentrance without having to think about
restoring variables is just great.
Or do you want to move flowscript just into the sitemap?
Bye,
Florian
P.S.: What ist [RT] ? And it would increase readibility if you introduce
abbreviations the first you use them (sorry, just my egoistic view ;-)
