cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [RT] The big picture of Servlet Service Framework
Date Thu, 16 Aug 2007 11:31:22 GMT
Dev at weitling pisze:
> 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

You are not limited to POSTing XML data. You can POST anything you like if you put service
calling 
at the beginning of the A's pipeline.

> - 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.

If you take a look at COCOON-2046 issue you will notice that comment:

   First implementation is going to be very naive and will not support caching nor SAX events
   forwarding (XML will be serialized/deserialized).

What's more, you will notice that it has subtask (COCOON-2050) with summary "Basic implementation
of 
postable source".

That indicates the current implementation is first step to achieve all goals like environment

forwarding and avoidance of xml serialization/parsing.

>> 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.

Conventions are intended to help developer, not limit her. In most scenarios, if developing
truly 
RESTful application you are going to have quite simple correspondence between exposed resources

(URIs) and your beans or even database structure. That's the case where convention can really
help.

Nevertheless the point is to write less code and do more but if you really need to handle
something 
unusual you are welcome to write more code (e.g. custom sitemap matcher implementation, or
sitemap 
snippet) to handle that specific case.

> 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?

No, no. I really want to get rid of sessions, continuations are variable restoring. So where
to move 
flow control? The answer is simple: to the rich client.

I forgot to say at the very beginning of my e-mail that RESTful design makes sense only if
on the 
other end is rich client. In this context 'rich' means the one that can fully take advantage
of HTTP 
protocol. It means that it must be able to make DELETE and PUT calls apart from casual GET
and POST. 
Most importantly, it means that client is able to handle it's state and make sensible request
to the 
server basing on client's state.

If you ask me about examples that I have in mind I can give you two:
   a) Ajax applications. They are capable enough to handle their own state and should be able
to 
deal with RESTful design. I have not evaluated this option extensively but there are plenty
of 
resources talking about REST and Ajax on the Internet.
   b) JavaFX. This technology is really new and it is still hard to find answers to all questions.

You can take a look at homepage of OpenJXF[1] to have an idea. Nevertheless, I think there
is a 
large Java's community interest in success of this technology and I believe we will be able
to 
easily write rich client applications using JavaFX. As soon as it will be possible to embed
JavaFX 
application into web page I'm going to evaluate how to integrate it with Cocoon (by giving
an 
examples). A long term goal would be to make implementation of CForms stateless and RESTful
and 
develop rich client for handling general CForms so you can get advanced widgets without hacking
HTML 
and numerous browsers.

You may think that this e-mail talks about very distant future. It may be true, but it's the
main 
purpose of [RT] e-mails to envision the future.

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

Cocoon has a long tradition of [RT] e-mails that stands for Random Thought. Since my e-mail
was 
addressed to devs are already familiar with this abbrevation and don't need introduction.

When inviting users willing to find out more about Cocoon's development I actually explained
what RT 
means. ;-)

[1] https://openjfx.dev.java.net/

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Mime
View raw message