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