Sorry, if this mail is not properly formatted - I have to use a mail frontend which
absolutely sucks. But it seems that I'm stuck to it for the next week.
Sylvain Wallez wrote:
> >You can totally confuse new cocoon users by telling them
> >that the serializer does not have to be the xml serializer.
> >Because they don't know the internal things of Cocoon which
> >we know. And it's not obvious for them.
> >
>
> I don't agree with the above : the first thing that a Cocoon user has to
> know are the concepts of generator, transformer and serializer. And all
> documents explaining these concepts explain the usage of SAX events (or
> at least XML documents) to communicate between components and the fact
> that the serializer translates SAX events to a byte stream.
>
> The concept of SAX-event pipeline is *the* fundamental concept of
> Cocoon. A such, a user not knowing this concept will understand about
> nothing to what Cocoon is and what it can do.
>
> But let's not argue about this, which isn't the real problem here.
Ok ;) - you missunderstood me above because I didn't give a good and clear explanation,
but you're right that we should not argue about this...so...let's continue
> >Let's be honest - do you know any framework etc. where you
> >have to specify things which are not used to define this
> >service? It's like implementing a method where you have to
> >add some statement at the beginning and at the end and then
> >later on they are ignored.
>
>
>Mmmh... what about languages like Eiffel where each method can have
>preconditions and postconditions (or the new "assert" in JDK 1.4) ?
>Depending on the runtime environment, these blocks may or may not be called.
This is a little bit different, as you can write pre- and post-
conditions in Eiffel but you don't have to. They're optional.
> >And I think if we have a special syntax for calling a service
> >it's nearly natural to have a special concept for defining
> >the service as well.
> >
>
> Yep. But once again, there is no new concept on the caller part. I admit
> the syntax is somewhat stretched on the callee and that we may want a
> particular syntax there, but certainly not on the caller part.
Ok, that's exactly where we different opinions - I really tend to
have a new syntax for the caller part as well - but if the overall
consensus is, that we don't need it - I will not block it - but
come up from time to time if users complain about it :)
> So what if we introduce some new statements to define incomplete
> pipelines to be used as pipeline services ? For example, a serialization
> service could be defined using :
>
> <map:begin-service/>
> <map:transform src="">> <map:serialize type="fo2pdf"/>
>
> and a transformation service could be defined using :
>
> <map:begin-service/>
> <map:transform src="">> <map:end-service/>
>
> That is <map:begin-service> replaces a <map:generator> that would be
> ignored and has to be used for transformation or serialization services.
> Similarily, <map:end-service> replaces a <map:serialize> that would be
> ignored and has to be used for generation or transformation services.
Roughly yes! I think this is more intuitiv und understandable.
> >And one interesting thought: I could imagine that as soon
> >as people can call a cocoon pipeline as a transformation
> >service they will want to call a web services doing the same
> >as well, so something like this comes into mind:
> ><generate src="">> ><call-pipeline src="" HREF="">http://server/transformation"/>
> ><serialize>
>
>
> Why should a remote web service be called with a "call-pipeline", which
> is a Cocoon concept ? Here again, we just want transformation. So this
> can be written :
>
> <generate src="">> <transform type="soap" src="" HREF="">http://server/transformation"/>
> <serialize/>
:) - you got me...
Carsten
