cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dev at weitling <>
Subject Re: [RT] The big picture of Servlet Service Framework
Date Thu, 16 Aug 2007 09:51:56 GMT
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?


P.S.: What ist [RT] ? And it would increase readibility if you introduce
abbreviations the first you use them (sorry, just my egoistic view ;-)

View raw message