You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/03/15 15:55:08 UTC
[RT] CallBack Style XML Handlers
In our quest for componentizing Cocoon, and making it work like a well
oiled machine for production environments, I got to thinking about
compiling the entire cocoon component into one large entity. In
order to realize dynamic aspects of the system, we need a callback
interface. Sort of a tangential CallBackListener to handle those
types of events and embed XML fragments into larger documents.
This works slightly different than the current form where we have
one pipeline of ContentHandlers. Each ContentHandler takes the
incomming XML and performs some manipulation on it, passing the
result to the next ContentHandler in line until we get to the
Serializer.
A side affect of this approach is a multiplicity of cache entries
based on session information and parameters for dynamic page content.
It would be more efficient to have one cache entry and a callback
mechanism to retrieve the necessary XML fragment. We can potentially
speed up the entire system by at least a factor of 2 (rough guestimate).
The way it would work is this:
The only data type we work with is the XMLSource. The XMLSource acts
as a generator for the next stage. The XMLSource can be a
ContentHandler that forwards events to the next ContentHandler in the
pipeline, OR it can be a CompiledXMLSource used in the Cache area
that calls the events as necessary. The interface looks something
like this:
interface XMLSource
{
handle( ContentHandler ch );
}
-o-
THE TIP OF THE ICEBERG
By working strictly with XMLSource, we don't care if the source is a
ContentHandler or an InputStream. All we care about is that the
information is sent to the next level. What it allows us to do is
implement a WriteBack style caching system. In essence if we have a
call for the URL "/news.html" we make all calls through the XMLSource
Resolver. The Resolver is able to work with the cache to compile the
XML at various stages of its growth. That way we can realize the dream
of optimizing away any and all transformations up to this point. In
essence, we can choose the XSLT parser based on operational correctness
because the Cache has compiled the result for us anyway.
So how does this work with dynamic content? Good question, and this is
where CallBack XML handlers work. By embedding CallBack events into the
compiled XML, we can generate the dynamic portions of the page at will.
Furthermore, we can set the system up so that callbacks are generated
asynchrounously and accessed via the XML Resolver mechanism. The
information will at least have a periodicity of one request. The XML
fragment can be requested multiple times, but only generated once.
-o-
THE REALLY COOL STUFF
By having the system work in this way, we solve another issue that has
been plaguing us. How do we create dynamic systems that are easy to
write and maintain. We have been focusing on using namespaces to mark
dynamic information like XInclude or ESQL. While they are decent
develomental tools, practice has shown that they don't scale as well
when you have to merge information from many datasets. The truth is
that the person who is writing everything typically will not remember
5 different namespace declarations. I personally have to go back and
copy the XML namespace declarations from other pages.
The callback mechanism allows us to embed events using only one
namespace for all dynamic logic. We would leverage the development
effort in Excalibur's scratchpad with the event based architecture
support systems. The CommandManager processes the actions as they come
in (with a controlled number of threads that are a function of the
number of processors on your machine). The interface for the callback
is simple. We extend the Command interface with XMLSource interface:
interface XMLCallBack extends Command
{
XMLSource getFragment( Parameters paramList );
}
The only thing we have to look out for is the XML event:
<call:event type="newsFlash">
<call:parameter name="example" value="Business"/>
</call:event>
We would have to extend the compiled XML to resolve these into one
callback method like this:
interface CallBackHandler
{
event( String type, Parameters paramList );
}
We kill a number of birds with one stone. We have a natural feel
for embedding dynamic pieces of generation, while maintaining the
ability to precompile the XML at each stage of the game. By extending
the Compiled XML spec to have one more callback type, we defer the
dynamic portions to controllable classes.
Furthermore, the sitemap controls the pipelines that the XMLSource
fragments go through. In essence allowing us to precompile those as
well.
In the end, it is conceivable to go so far as to specify a Compiled
Stream protocol that has CallBacks. We can explore compiled components
at just about any level. However, this approach helps solve some
immediate needs, as well as allows us to use the existing components
to generate our XMLSources. Hopefully we can explore methods of
generating CallBack fragments from XSP pages, allowing us to use that
approach in a more efficient manner.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Ivelin Ivanov <iv...@iname.com>.
> Now, is there any example of use that cannot be made to work in the
> above scenario?
>
> Please, submit your examples to convince us.
Cannot give such example.
Jeremy Quinn elegantly resolved and implemented in <slash-edit/> a solution
for the class of problems I was targeting.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Saturday, March 23, 2002 3:35 AM
Subject: Re: [RT] CallBack Style XML Handlers
> Ivelin Ivanov wrote:
> >
> > I am looking for short input. Do you think that an XPath selector
(working
> > against the current SAX stream) makes sence or not ?
>
> My personal opinion is that matadata should be 'outside' the pipeline,
> and data inside the pipeline. In such a world, a pipeline-aware selector
> wouldn't be needed because pipeline driving would be done reacting on
> metadata and not on data.
>
> In the HTTP request sense, metadata are headers and data is payload.
>
> Now, is there any example of use that cannot be made to work in the
> above scenario?
>
> Please, submit your examples to convince us.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Stefano Mazzocchi <st...@apache.org>.
Ivelin Ivanov wrote:
>
> I am looking for short input. Do you think that an XPath selector (working
> against the current SAX stream) makes sence or not ?
My personal opinion is that matadata should be 'outside' the pipeline,
and data inside the pipeline. In such a world, a pipeline-aware selector
wouldn't be needed because pipeline driving would be done reacting on
metadata and not on data.
In the HTTP request sense, metadata are headers and data is payload.
Now, is there any example of use that cannot be made to work in the
above scenario?
Please, submit your examples to convince us.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Ivelin Ivanov <iv...@iname.com>.
Stefano,
>
> Berin clearly stated that it has nothing to do with the sitemap, so the
> 'pipe-aware selector' problem is still wide open.
I am looking for short input. Do you think that an XPath selector (working
against the current SAX stream) makes sence or not ?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> The main issue I am trying to address is precompiling the cocoon
> webapp or cocoon component so that the performance and scalability
> of Cocoon will blow people away.
Know what? I get very happy when people blow me away :-)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Nicola Ken Barozzi wrote:
> >
> > Dear Berin,
> > IMNSHO with this RT you have basically managed to solve the Cocoon
> > Generation problem :-) Shall we call it NG ie New Generation? ;-)
> >
> > IIUC, this RT sums up all discussions on XSP2, xForge, Cocoon sub
> > component model, Dispatcher&Adapter and integrates all of them with
> > caching.
>
> Probably I'm missing something, but I really can't see this.
Well XSP Next Gen could definitely work with this approach.
> You are trying to 'precompile' all cacheable parts of a
> pipeline result and let just the dynamic hooks, I really
> can't see how this can be done.
I'm working on an implementation. Just to get started, it will be
a simple XInclude callback. Once the proof of concept is generated,
I will look at extending it to the simple markups we have like
Request, and Session.
> > It appears that all the afromentioned proposals are
> implementable on
> > top of this RT, with the non trivial adding of caching.
>
> Berin clearly stated that it has nothing to do with the
> sitemap, so the 'pipe-aware selector' problem is still wide open.
The main issue I am trying to address is precompiling the cocoon
webapp or cocoon component so that the performance and scalability
of Cocoon will blow people away.
At the same time, I am attempting to address the issues dealing with
pages that have information of varying periodicities in a simple and
elegant manner. A time of day XMLSource may change every second,
but the news might only be updated every minute. Still other resources
are completely static.
If a composite page uses all three of these elements, the cache entry
for the entire page would change every second, even though the
pertinent information on the page won't change nearly that often.
>
> > You blew my mind, and I think I finally say the light :-o
>
> Don't want to rain on the party, but I didn't see any light at all.
>
> > If you dont get replies, usually it's because your proposal is
> > perfect, or they don't understand it.
>
> I marked it for futher reading because I couldn't grasp the
> intentions, I think I need more input.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Dear Berin,
> IMNSHO with this RT you have basically managed to solve the Cocoon
> Generation problem :-)
> Shall we call it NG ie New Generation? ;-)
>
> IIUC, this RT sums up all discussions on XSP2, xForge, Cocoon sub component
> model, Dispatcher&Adapter and integrates all of them with caching.
Probably I'm missing something, but I really can't see this.
You are trying to 'precompile' all cacheable parts of a pipeline result
and let just the dynamic hooks, I really can't see how this can be done.
> It appears that all the afromentioned proposals are implementable on top of
> this RT, with the non trivial adding of caching.
Berin clearly stated that it has nothing to do with the sitemap, so the
'pipe-aware selector' problem is still wide open.
> You blew my mind, and I think I finally say the light :-o
Don't want to rain on the party, but I didn't see any light at all.
> If you dont get replies, usually it's because your proposal is perfect, or
> they don't understand it.
I marked it for futher reading because I couldn't grasp the intentions,
I think I need more input.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, March 18, 2002 11:54 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] CallBack Style XML Handlers
>
> From: "Berin Loritsch" <bl...@apache.org>
>
> > interface XMLSource
> > {
> > handle( ContentHandler ch, CallBackHandler cbh );
> >}
> >
> > interface XMLCallBack extends Command
> > {
> > XMLSource getFragment( Parameters paramList );
> >}
> >
> >interface CallBackHandler
> >{
> > XMLSource event( String type, Parameters paramList );
> >}
>
> I'm a bit slow maybe, but I don't see how these interfaces should call
> each
> other...
> Since I'm not familiar with the Excalibur event stuff, how would the
> call
> sequence be?
We start with the XMLSource. We give it a ContentHandler and a
CallBackHandler
Normal SAX events go directly to the ContentHandler, but when a
CallBackEvent is generated, it goes to the CallBackHandler. The
CallBackHandler resolves the "type" name with the specific XMLCallBack.
The CallBackHandler then executes the getFragment( Parameters params )
And returns the resulting XMLSource.
The original XMLSource then calls the handle() method on the embedded
Fragment. With in XInclude example, let us suppose we have the
Following scenario:
XMLSource [main]
{
handle( ContentHandler ch, CallBackHandler cb )
{
ch.startDocument();
ch.startElement( .... );
XMLSource included = cb.event( "xinclude", paramList );
Included.handle(ch, cb);
ch.endElement( .... );
ch.endDocument();
}
}
Internal to the CallBackHandler, we would have this:
CallBackHandler
{
event( String type, Parameters paramlist )
{
XMLCallBack callback = (XMLCallBack) m_eventTypes.get( type );
return callback.getFragment( paramlist );
}
}
> Another thing; here we have a Parameters object and a String being
> passed.
> From my experience in Swing editing stuff, where a lot of events go
> roung,
> it's best not to use Objects in callbacks, since this creates lots of
> object
> creation and garbage.
> As type we could use int, and an array of ints as parameters for
> example.
We already pass Parameters objects to all our Sitemap components. The
Weight of the Parameters is not heavy at all. We should be able to run
It without problems.
>
> > <call:event type="newsFlash">
> > <call:parameter name="example" value="Business"/>
> < </call:event>
>
> Hmmm... what about having other xml defined inside? How would that
> work out?
KISS (Keep It Simple Stupid)
By changing the internal markup to be XML, we would need to pass
Configuration objects instead of a simple parameters object. Most
Run-time customizations can be best handled with simple name/value
Pairs. Until we see a *real* need, I would rather stay away from
The arbitrary embedded XML approach. You were complaining about
The Parameters object before--the complexity of this would be worse,
For very little gain.
I am also thinking of simplicity of extending the CompiledXML spec.
> > Does this sound good as a starting point?
>
> If I ask a couple more questions like this, you're gonna come out with
> an
> implementation! ;-D
Awesome!
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Berin Loritsch" <bl...@apache.org>
> interface XMLSource
> {
> handle( ContentHandler ch, CallBackHandler cbh );
>}
>
> interface XMLCallBack extends Command
> {
> XMLSource getFragment( Parameters paramList );
>}
>
>interface CallBackHandler
>{
> XMLSource event( String type, Parameters paramList );
>}
I'm a bit slow maybe, but I don't see how these interfaces should call each
other...
Since I'm not familiar with the Excalibur event stuff, how would the call
sequence be?
Another thing; here we have a Parameters object and a String being passed.
>From my experience in Swing editing stuff, where a lot of events go roung,
it's best not to use Objects in callbacks, since this creates lots of object
creation and garbage.
As type we could use int, and an array of ints as parameters for example.
> <call:event type="newsFlash">
> <call:parameter name="example" value="Business"/>
< </call:event>
Hmmm... what about having other xml defined inside? How would that work out?
> The first thing we need to do is put the interfaces (after we agree on
> Them) into CVS. As a starting point, we can automagically convert
> XInclude directives into XMLCallBack events. That way, we don't need
> a separate transformer, and include operations that would normally be
> expensive can be made quick and painless.
+1
> Once we have the XInclude set in place, we can take advantage of a small
> cache size, and look into converting other pieces over to the policy
> as well.
+1
> Does this sound good as a starting point?
If I ask a couple more questions like this, you're gonna come out with an
implementation! ;-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
> I maybe a bit too agressive here, so please let me know if so:
>
> Can the caching logic be shifted up one step above the
> CallBackHandler? How about a Cacheable CallBackHandlerInterface
>
> interface CacheableCallBackHandler
> {
> boolean hasChanged( String type, Parameters paramList );
> XMLSource event( String type, Parameters paramList );
> }
>
This is not ThreadSafe. Not to meantion, the caching implementation
Can and should be handled inside the CallBackHandler. The item will
Resolve to a cached XMLSource, so we have the same effect without the
Unnecessary complexities of shifting this logic to the user classes.
IMNSHO, a cache should be as invisible as you can possibly make it.
This is one step to enable that to happen.
<snip/>
>
> From your email:
> > It is important to preserve the order of the callback
> events, but not
> >necessarily when they are first called. For instance, we
> can choose to
> >execute the callbacks when we first resolve the source. We
> must include
> >the results at the location where they are needed.
>
> It would be really cool if an XMLSource (which is otherwise
> static/cacheable) can somehow iterate before starting to fire
> events through its callback segments and if they all haven't
> changed then the whole XMLSource can report that it hasn't
> changed, thus the next transformation can be skipped.
Exactamundo. Now your getting it!
> Maybe another modification of the code above (although I
> don't quite understand yet the current caching mechanism ):
>
> XMLSource [main]
> {
>
> boolean hasChanged()
> {
> iterate over callback elements and if none has changed
> then return true, so that the whole document is pulled from the cache
> otherwise return false
> }
>
> // if some of the callback handlers HAS changed though,
> we'll still need to do this
> handle( ContentHandler ch, CallBackHandler cb )
> {
> ch.startDocument();
> ch.startElement( .... );
>
> XMLSource included;
> if ( cb.hasChanged("xinclude", paramList) )
> {
> included = cb.event( "xinclude", paramList );
> }
> else
> {
> included = pullOutFromCache();
> }
>
> Included.handle(ch, cb);
>
> ch.endElement( .... );
> ch.endDocument();
> }
> }
I would not do that. The purpose of the XMLSource and the
Callback system is to allow caching fragments of the document,
And letting those cached fragments usable in multiple documents.
By not poluting the cached XMLSource document, we can effectively
Not have to have a new entry for each fully resolved document.
We are dealing with SAX fragments, so the cost of assembling
A larger document from smaller pieces is essentially zero.
>
>
> > The first thing we need to do is put the interfaces (after
> we agree on
> > Them) into CVS. As a starting point, we can automagically convert
> > XInclude directives into XMLCallBack events. That way, we
> don't need
> > a separate transformer, and include operations that would
> normally be
> > expensive can be made quick and painless.
> >
> > Once we have the XInclude set in place, we can take advantage of a
> > small cache size, and look into converting other pieces over to the
> > policy as well.
> >
> > Does this sound good as a starting point?
>
>
> You bet it does !
>
>
> Ivelin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Ivelin Ivanov <iv...@iname.com>.
I maybe a bit too agressive here, so please let me know if so:
Can the caching logic be shifted up one step above the CallBackHandler?
How about a Cacheable CallBackHandlerInterface
interface CacheableCallBackHandler
{
boolean hasChanged( String type, Parameters paramList );
XMLSource event( String type, Parameters paramList );
}
hence (from your other example):
XMLSource [main]
{
handle( ContentHandler ch, CallBackHandler cb )
{
ch.startDocument();
ch.startElement( .... );
XMLSource included;
if ( cb.hasChanged("xinclude", paramList) )
{
included = cb.event( "xinclude", paramList );
}
else
{
included = pullOutFromCache();
}
Included.handle(ch, cb);
ch.endElement( .... );
ch.endDocument();
}
}
>From your email:
> It is important to preserve the order of the callback
>events, but not necessarily when they are first called. For instance,
>we can choose to execute the callbacks when we first resolve the source.
>We must include the results at the location where they are needed.
It would be really cool if an XMLSource (which is otherwise
static/cacheable) can somehow iterate before starting to fire events through
its callback segments and if they all haven't changed then the whole
XMLSource can report that it hasn't changed, thus the next transformation
can be skipped.
Maybe another modification of the code above (although I don't quite
understand yet the current caching mechanism ):
XMLSource [main]
{
boolean hasChanged()
{
iterate over callback elements and if none has changed then return
true, so that the whole document is pulled from the cache
otherwise return false
}
// if some of the callback handlers HAS changed though, we'll still need
to do this
handle( ContentHandler ch, CallBackHandler cb )
{
ch.startDocument();
ch.startElement( .... );
XMLSource included;
if ( cb.hasChanged("xinclude", paramList) )
{
included = cb.event( "xinclude", paramList );
}
else
{
included = pullOutFromCache();
}
Included.handle(ch, cb);
ch.endElement( .... );
ch.endDocument();
}
}
> The first thing we need to do is put the interfaces (after we agree on
> Them) into CVS. As a starting point, we can automagically convert
> XInclude directives into XMLCallBack events. That way, we don't need
> a separate transformer, and include operations that would normally be
> expensive can be made quick and painless.
>
> Once we have the XInclude set in place, we can take advantage of a small
> cache size, and look into converting other pieces over to the policy
> as well.
>
> Does this sound good as a starting point?
You bet it does !
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > >
> > > Dear Berin,
> > > Or without joking: "Where do we go from here?"
> >
> > Obviously, we need to have someone step forward and start with the
> > CallBackHandler and any mods to the Compiled XML stream classes we
> > have.
> >
> > Once that is done, we can start integrating it with all the other
> > stuff we have now.
> >
> > Are there any volunteers?
>
> I *would like* to volunteer, but am a bit time constrained ATM.
>
> Vadim, since you volunteered, could you come up with a concrete
> implementation proposal? (NKB hint: can xForge be upgraded to this
> RT?)
> This way we could divide tasks in appropriate.
>
> Berin, do you have any hint on what is concretely needed to be done?
>
> The possible result is there to see, but I can't yet see the path.
>
> Gee, this is cool!
We need a CallBackHandler created. My first stab at the interface would
Be:
interface XMLSource
{
handle( ContentHandler ch, CallBackHandler cbh );
}
interface XMLCallBack extends Command
{
XMLSource getFragment( Parameters paramList );
}
interface CallBackHandler
{
XMLSource event( String type, Parameters paramList );
}
The CallBackHandler takes care of resolving the event type to
execute, or even pull from cache. The cool thing here is
that we can pre-run the XMLCallBacks that will be used in
the request. We would have to provide a hint to the CallBackHandler
to make it's caching policy more efficient. IOW, What is the
periodicity of the event type? That can be handled in the sitemap
definition, because it is not important to the pipeline. I
see different styles of periodicity:
Constant/Static -- Does not change until the source changes
Request -- lasts for one request
Session -- lasts for an entire session
Time-Based -- lasts for the specified number of milliseconds
Those periodicities will allow us to be smarter about implementing
our caching policy. It also allows us to only generate parts of
a page only once and use it multiple times.
The snippet here is an example of the XML representation of a
CallBack.
<call:event type="newsFlash">
<call:parameter name="example" value="Business"/>
</call:event>
Working Namespace definition: xmlns:call="http://apache.org/call/1.0"
The Compiled XML streams that we have need to collapse that snippet into
one event that gets called to the CallBackHandler.
The CallBackHandler can be a completely separate entity, or even a first
Class component. It is important to preserve the order of the callback
events, but not necessarily when they are first called. For instance,
we can choose to execute the callbacks when we first resolve the source.
We must include the results at the location where they are needed.
One of the reasons I had the XMLCallBack implement Command (from the
command package in Excalibur scratchpad) is to enable the asynchronous
pregeneration of the events, allowing them to be used when they are
done being resolved. That can be a later implementation detail though.
The first thing we need to do is put the interfaces (after we agree on
Them) into CVS. As a starting point, we can automagically convert
XInclude directives into XMLCallBack events. That way, we don't need
a separate transformer, and include operations that would normally be
expensive can be made quick and painless.
Once we have the XInclude set in place, we can take advantage of a small
cache size, and look into converting other pieces over to the policy
as well.
Does this sound good as a starting point?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Berin Loritsch" <bl...@apache.org>
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > Dear Berin,
> > IMNSHO with this RT you have basically managed to solve the Cocoon
> > Generation problem :-)
> > Shall we call it NG ie New Generation? ;-)
>
> That good?!
I think so.
This stuff has been going round my head for years, in discussions with
Ricardo and others, and I think that you finally managed to put it in
writing.
> Cool, so who wants to start on it? I'm swamped, and I have some
> other work I have to work on.
Ahem, we are all swamped ;-P
> > Or without joking: "Where do we go from here?"
>
> Obviously, we need to have someone step forward and start with the
> CallBackHandler and any mods to the Compiled XML stream classes we
> have.
>
> Once that is done, we can start integrating it with all the other
> stuff we have now.
>
> Are there any volunteers?
I *would like* to volunteer, but am a bit time constrained ATM.
Vadim, since you volunteered, could you come up with a concrete
implementation proposal? (NKB hint: can xForge be upgraded to this RT?)
This way we could divide tasks in appropriate.
Berin, do you have any hint on what is concretely needed to be done?
The possible result is there to see, but I can't yet see the path.
Gee, this is cool!
NOTE: Mr. Reader, if you don't understand what we are talking about, dont
mind. We don't know either ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Ivelin Ivanov <iv...@iname.com>.
I'd be interested to share some of my spare time (as little as it is),
although I will keep my focus on the Form Handling and Validation
infrastructure.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: <co...@xml.apache.org>; "'Nicola Ken Barozzi'"
<ni...@apache.org>
Sent: Monday, March 18, 2002 9:33 AM
Subject: RE: [RT] CallBack Style XML Handlers
> > -----Original Message-----
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > Sent: Monday, March 18, 2002 10:13 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: [RT] CallBack Style XML Handlers
> >
> > Dear Berin,
> > IMNSHO with this RT you have basically managed to solve the Cocoon
> > Generation problem :-)
> > Shall we call it NG ie New Generation? ;-)
>
> That good?!
>
> >
> > IIUC, this RT sums up all discussions on XSP2, xForge, Cocoon sub
> > component
> > model, Dispatcher&Adapter and integrates all of them with caching.
> > It appears that all the afromentioned proposals are implementable on
> > top of
> > this RT, with the non trivial adding of caching.
> >
> > You blew my mind, and I think I finally say the light :-o
>
> Cool, so who wants to start on it? I'm swamped, and I have some
> other work I have to work on.
>
> >
> > If you dont get replies, usually it's because your proposal is
> > perfect, or
> > they don't understand it.
> > Which makes me say: "When are you going to implement it?" ;-)
> >
> > Or without joking: "Where do we go from here?"
>
> Obviously, we need to have someone step forward and start with the
> CallBackHandler and any mods to the Compiled XML stream classes we
> have.
>
> Once that is done, we can start integrating it with all the other
> stuff we have now.
>
> Are there any volunteers?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Monday, March 18, 2002 10:13 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] CallBack Style XML Handlers
>
> Dear Berin,
> IMNSHO with this RT you have basically managed to solve the Cocoon
> Generation problem :-)
> Shall we call it NG ie New Generation? ;-)
That good?!
>
> IIUC, this RT sums up all discussions on XSP2, xForge, Cocoon sub
> component
> model, Dispatcher&Adapter and integrates all of them with caching.
> It appears that all the afromentioned proposals are implementable on
> top of
> this RT, with the non trivial adding of caching.
>
> You blew my mind, and I think I finally say the light :-o
Cool, so who wants to start on it? I'm swamped, and I have some
other work I have to work on.
>
> If you dont get replies, usually it's because your proposal is
> perfect, or
> they don't understand it.
> Which makes me say: "When are you going to implement it?" ;-)
>
> Or without joking: "Where do we go from here?"
Obviously, we need to have someone step forward and start with the
CallBackHandler and any mods to the Compiled XML stream classes we
have.
Once that is done, we can start integrating it with all the other
stuff we have now.
Are there any volunteers?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Dear Berin,
> IMNSHO with this RT you have basically managed to solve the Cocoon
> Generation problem :-)
> Shall we call it NG ie New Generation? ;-)
>
> IIUC, this RT sums up all discussions on XSP2, xForge, Cocoon sub
component
> model, Dispatcher&Adapter and integrates all of them with caching.
> It appears that all the afromentioned proposals are implementable on
top of
> this RT, with the non trivial adding of caching.
>
> You blew my mind, and I think I finally say the light :-o
>
> If you dont get replies, usually it's because your proposal is
perfect, or
> they don't understand it.
> Which makes me say: "When are you going to implement it?" ;-)
>
> Or without joking: "Where do we go from here?"
Count me in. The idea is quite interesting. I'm still thinking on this
RT.
Vadim
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dear Berin,
IMNSHO with this RT you have basically managed to solve the Cocoon
Generation problem :-)
Shall we call it NG ie New Generation? ;-)
IIUC, this RT sums up all discussions on XSP2, xForge, Cocoon sub component
model, Dispatcher&Adapter and integrates all of them with caching.
It appears that all the afromentioned proposals are implementable on top of
this RT, with the non trivial adding of caching.
You blew my mind, and I think I finally say the light :-o
If you dont get replies, usually it's because your proposal is perfect, or
they don't understand it.
Which makes me say: "When are you going to implement it?" ;-)
Or without joking: "Where do we go from here?"
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Ivelin Ivanov [mailto:ivelin@iname.com]
> Sent: Monday, March 18, 2002 11:49 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [RT] CallBack Style XML Handlers
>
>
> > > Is your callback mechanism a generalization of the <aggregator>
> component
> > > and a way to hint dynamic parts?
> > > If I understood correctly, if a callback returns the same
> document
> > > (same
> > > content) as it did once before, then eventually a "smart"
> XSLT processor
> > > (which cached earlier results) would still know that its (the
> callback's)
> > > portion of the document didn't change and shouldn't be
> re-processed.
> >
> >
> > That is pretty close.
> >
> > Let's assume for instance that the XSP markup looks something like
> > this:
> >
> > <inbox xmlns:xsp="http://apache.org/xsp"
> > xmlns:mycom="http://mycom.com/logicsheet/1.0">
> > <mycom:user/>
> > <mycom:inbox/>
> > </inbox>
>
> How would this work if I slightly modified the piece above:
>
> <mycom:user>
> Name: <mycom:lastName/>, </mycom:lastName>
> <br/>
> email: <mycom:email/>
> </mycom:user>
>
> Is that allowed, or instead one'd have to do:
>
> document1.xml
> <inbox xmlns:xsp="http://apache.org/xsp"
> xmlns:mycom="http://mycom.com/logicsheet/1.0">
> <mycom:user/>
> <mycom:inbox/>
> </inbox>
>
> document2html.xsl
You can do whatever you like, but the compilation would
Transform those sections into callbacks. The CallBackHandler
would insert the relevant snippet
>
> ..
> <xsl:template name="userprocess>
> Name: <xsl:value-of select="lastName">, <xsl:value-of
> select="firstName"> ...
>
> Then the sitemap pipeline will be like:
>
> <map:generate src="document1.xml"/>
> <map:transform type="XInclude"/>
> <map:transform src="document2html.xsl"/>
> ...
>
> Does my question make any sence?
Actually, once the compiled XML is generated, the XInclude transformer
Layer is not needed at all.
It is automatically executed as needed
> > For each session, the user information is completely static. The
> > inbox doesn't necessarily change that often either. The
> compiled XML
> > spec needs to mark callback events in a special manner so that they
> > are not lost in each transformation
> > stage. The output can be something like this:
>
> If I am not mistaken, since the call-backs are simply xml
> elements with specific name space, then as long as they are
> preserved as such along with their namespace references
> during multiple transformation stages, then it shouldn't take
> any extra work to keep them from being lost.
The trick is with cached elements that have dynamic elements.
Instead of using several cache entries for whole copies of
An entire page,we have one entry for the page, which dynamically
Includes the other elements as needed. This allows us to have
Different periodicities for *parts* of a page--without cluttering
The cache with unnecessary copies of the same resource.
>
>
> >
> > <html>
> > <h1><callback:event name="mycom:user"/></h1>
> > <h2>Inbox</h2>
> > <table>
> > <tr>
> > <th>Name</th>
> > <th>Status</th>
> > <th>Date</th>
> > </tr>
> > <tr>
> > <callback:event name="mycom:inbox"/>
> > </tr>
> > </table>
> > </html>
> >
> > The callback mechanism will resolve the resource name to the proper
> > XSP fragment.
>
> At what points of the pipeline will the substitutions happen.
> Would one explicitely use XInclude transformers at each point
> in the pipeline when callbacks should be called and resolved
> to xml? Also at what point does the <callback> element get
> converted to an actual XML Source fed by the call-back
> function. What is the benefit of the intermediate stage ?
> <myspace:user/> -> <callback:event .../> -> XML Source Could
> it be just <myspace:user/> -> XML Source
My next step will be to work with the compressed/compiled XML,
That will encode those events.
>
>
>
> Keep the good ideas flowing so we can start on the
> implementation asap.
>
> Ivelin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Ivelin Ivanov <iv...@iname.com>.
> > Is your callback mechanism a generalization of the <aggregator>
component
> > and a way to hint dynamic parts?
> > If I understood correctly, if a callback returns the same document (same
> > content) as it did once before, then eventually a "smart" XSLT processor
> > (which cached earlier results) would still know that its (the
callback's)
> > portion of the document didn't change and shouldn't be re-processed.
>
>
> That is pretty close.
>
> Let's assume for instance that the XSP markup looks something like this:
>
> <inbox xmlns:xsp="http://apache.org/xsp"
> xmlns:mycom="http://mycom.com/logicsheet/1.0">
> <mycom:user/>
> <mycom:inbox/>
> </inbox>
How would this work if I slightly modified the piece above:
<mycom:user>
Name: <mycom:lastName/>, </mycom:lastName>
<br/>
email: <mycom:email/>
</mycom:user>
Is that allowed, or instead one'd have to do:
document1.xml
<inbox xmlns:xsp="http://apache.org/xsp"
xmlns:mycom="http://mycom.com/logicsheet/1.0">
<mycom:user/>
<mycom:inbox/>
</inbox>
document2html.xsl
..
<xsl:template name="userprocess>
Name: <xsl:value-of select="lastName">, <xsl:value-of select="firstName">
...
Then the sitemap pipeline will be like:
<map:generate src="document1.xml"/>
<map:transform type="XInclude"/>
<map:transform src="document2html.xsl"/>
...
Does my question make any sence?
>
> For each session, the user information is completely static. The inbox
> doesn't
> necessarily change that often either. The compiled XML spec needs to mark
> callback events in a special manner so that they are not lost in each
> transformation
> stage. The output can be something like this:
If I am not mistaken, since the call-backs are simply xml elements with
specific name space, then as long as they are preserved as such along with
their namespace references during multiple transformation stages, then it
shouldn't take any extra work to keep them from being lost.
>
> <html>
> <h1><callback:event name="mycom:user"/></h1>
> <h2>Inbox</h2>
> <table>
> <tr>
> <th>Name</th>
> <th>Status</th>
> <th>Date</th>
> </tr>
> <tr>
> <callback:event name="mycom:inbox"/>
> </tr>
> </table>
> </html>
>
> The callback mechanism will resolve the resource name to the proper XSP
> fragment.
At what points of the pipeline will the substitutions happen.
Would one explicitely use XInclude transformers at each point in the
pipeline when callbacks should be called and resolved to xml?
Also at what point does the <callback> element get converted to an actual
XML Source fed by the call-back function.
What is the benefit of the intermediate stage ?
<myspace:user/> -> <callback:event .../> -> XML Source
Could it be just
<myspace:user/> -> XML Source
Keep the good ideas flowing so we can start on the implementation asap.
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Berin Loritsch <bl...@apache.org>.
----- Original Message -----
From: "Ivelin Ivanov" <iv...@iname.com>
To: <co...@xml.apache.org>
Sent: Sunday, March 17, 2002 12:10 PM
Subject: Re: [RT] CallBack Style XML Handlers
>
> Berin,
>
>
> I don't have high enough rank or knowledge of Cocoon to discuss this
> subject and should probably stay quiet, but since no one else seems to
> respond,
> I'll take the risk.
>
>
> 1) If you have been following the threads on HTML form binding and
> validation, you have noticed that one problem is how to branch the
pipeline
> based on transformer output. Two proposed solutions emerged:
> a) Implementing a Transformer with a "side-effect" of sticking in the
> sitemap a parameter which hints the result of the actual transformation
> b) Implementing an XPath selector, which evaluates its test attribute
> against the result of the preceding transformation. I'm actually a bit
> surprised that threre isn't one implemented yet. After all the user's
guide
> says: "The selector syntax is similar to the XSLT <xsl:test/> element". I
> know that the current Selector interface doesn't allow access to the SAX
> stream, but shouldn't that change?
No, The Selector is specific to the Sitemap. It is used to select which
pipeline to use--not which XML fragment to use. Besides, XSLT has its
own selector like syntax, so it would be an unnecessary duplication of
effort.
> It sounds to me that these are both somewhat in line with your proposed
> extension. If so can you elaborate a bit more on the subject with more
> implementation details and sample scenarios, say some multi page web
wizard.
The main thing I am proposing is a way to compile an XML document, and
keep the "hooks" where dynamic content is inserted. That way, we can have a
more efficient cache implementation, and a pipeline that truly
"short-circuits"
unnecessary transformations.
XSLT can work on fragments of XML as whole documents.
> 2) XSL is a pure functional language. As such it carries one of the main
> properties of these languages. There are no side effects. No matter how
many
> times a stylesheet is called with the same input document and parameters,
> the output will always be the same. This extends to the following:
> "Applying subsequent transformations over a document can be optimized to
> only process the parts of the document which changed". Many web pages are
> mostly static and they have a few dynamic sections which change from one
> display to the next.
> Cocoon's <aggregator> component allows for "manual" processing
optimization,
> when the changes are known upfront and this allows for better caching of
> separate parts, which don't change together.
> Having working implementations of pure functional languages for over 10
> years now, I would expect that the "HotSpot" version of XSLT is not too
far
> from reality.
The XML Callback mechanism is a conceptually simple approach, and allows
the developer to do some really powerful things without unnecessary work.
This
lowers the load on the processor, and increases scalability.
>
> Is your callback mechanism a generalization of the <aggregator> component
> and a way to hint dynamic parts?
> If I understood correctly, if a callback returns the same document (same
> content) as it did once before, then eventually a "smart" XSLT processor
> (which cached earlier results) would still know that its (the callback's)
> portion of the document didn't change and shouldn't be re-processed.
That is pretty close.
Let's assume for instance that the XSP markup looks something like this:
<inbox xmlns:xsp="http://apache.org/xsp"
xmlns:mycom="http://mycom.com/logicsheet/1.0">
<mycom:user/>
<mycom:inbox/>
</inbox>
For each session, the user information is completely static. The inbox
doesn't
necessarily change that often either. The compiled XML spec needs to mark
callback events in a special manner so that they are not lost in each
transformation
stage. The output can be something like this:
<html>
<h1><callback:event name="mycom:user"/></h1>
<h2>Inbox</h2>
<table>
<tr>
<th>Name</th>
<th>Status</th>
<th>Date</th>
</tr>
<tr>
<callback:event name="mycom:inbox"/>
</tr>
</table>
</html>
The callback mechanism will resolve the resource name to the proper XSP
fragment.
Now, the cache is already set with this information available, at least for
the user
information.
When the request comes for the inbox, the resolver makes a quick resolution
and the
final results come out:
<html>
<h1>Berin Loritsch</h1>
<h2>Inbox</h2>
<table>
<tr>
<th>Name</th>
<th>Status</th>
<th>Date</th>
</tr>
<tr>
<td>First Item to work on</td>
<td>NEW</td>
<td>03/13/2002</td>
</tr>
</table>
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] CallBack Style XML Handlers
Posted by Ivelin Ivanov <iv...@iname.com>.
Berin,
I don't have high enough rank or knowledge of Cocoon to discuss this
subject and should probably stay quiet, but since no one else seems to
respond,
I'll take the risk.
1) If you have been following the threads on HTML form binding and
validation, you have noticed that one problem is how to branch the pipeline
based on transformer output. Two proposed solutions emerged:
a) Implementing a Transformer with a "side-effect" of sticking in the
sitemap a parameter which hints the result of the actual transformation
b) Implementing an XPath selector, which evaluates its test attribute
against the result of the preceding transformation. I'm actually a bit
surprised that threre isn't one implemented yet. After all the user's guide
says: "The selector syntax is similar to the XSLT <xsl:test/> element". I
know that the current Selector interface doesn't allow access to the SAX
stream, but shouldn't that change?
It sounds to me that these are both somewhat in line with your proposed
extension. If so can you elaborate a bit more on the subject with more
implementation details and sample scenarios, say some multi page web wizard.
2) XSL is a pure functional language. As such it carries one of the main
properties of these languages. There are no side effects. No matter how many
times a stylesheet is called with the same input document and parameters,
the output will always be the same. This extends to the following:
"Applying subsequent transformations over a document can be optimized to
only process the parts of the document which changed". Many web pages are
mostly static and they have a few dynamic sections which change from one
display to the next.
Cocoon's <aggregator> component allows for "manual" processing optimization,
when the changes are known upfront and this allows for better caching of
separate parts, which don't change together.
Having working implementations of pure functional languages for over 10
years now, I would expect that the "HotSpot" version of XSLT is not too far
from reality.
Is your callback mechanism a generalization of the <aggregator> component
and a way to hint dynamic parts?
If I understood correctly, if a callback returns the same document (same
content) as it did once before, then eventually a "smart" XSLT processor
(which cached earlier results) would still know that its (the callback's)
portion of the document didn't change and shouldn't be re-processed.
I guess you had enough of my philosophical outburst.
Your turn.
Cheers,
Ivelin
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: <co...@xml.apache.org>
Sent: Friday, March 15, 2002 8:55 AM
Subject: [RT] CallBack Style XML Handlers
> In our quest for componentizing Cocoon, and making it work like a well
> oiled machine for production environments, I got to thinking about
> compiling the entire cocoon component into one large entity. In
> order to realize dynamic aspects of the system, we need a callback
> interface. Sort of a tangential CallBackListener to handle those
> types of events and embed XML fragments into larger documents.
>
> This works slightly different than the current form where we have
> one pipeline of ContentHandlers. Each ContentHandler takes the
> incomming XML and performs some manipulation on it, passing the
> result to the next ContentHandler in line until we get to the
> Serializer.
>
> A side affect of this approach is a multiplicity of cache entries
> based on session information and parameters for dynamic page content.
> It would be more efficient to have one cache entry and a callback
> mechanism to retrieve the necessary XML fragment. We can potentially
> speed up the entire system by at least a factor of 2 (rough guestimate).
>
> The way it would work is this:
>
> The only data type we work with is the XMLSource. The XMLSource acts
> as a generator for the next stage. The XMLSource can be a
> ContentHandler that forwards events to the next ContentHandler in the
> pipeline, OR it can be a CompiledXMLSource used in the Cache area
> that calls the events as necessary. The interface looks something
> like this:
>
> interface XMLSource
> {
> handle( ContentHandler ch );
> }
>
> -o-
>
>
> THE TIP OF THE ICEBERG
>
> By working strictly with XMLSource, we don't care if the source is a
> ContentHandler or an InputStream. All we care about is that the
> information is sent to the next level. What it allows us to do is
> implement a WriteBack style caching system. In essence if we have a
> call for the URL "/news.html" we make all calls through the XMLSource
> Resolver. The Resolver is able to work with the cache to compile the
> XML at various stages of its growth. That way we can realize the dream
> of optimizing away any and all transformations up to this point. In
> essence, we can choose the XSLT parser based on operational correctness
> because the Cache has compiled the result for us anyway.
>
> So how does this work with dynamic content? Good question, and this is
> where CallBack XML handlers work. By embedding CallBack events into the
> compiled XML, we can generate the dynamic portions of the page at will.
> Furthermore, we can set the system up so that callbacks are generated
> asynchrounously and accessed via the XML Resolver mechanism. The
> information will at least have a periodicity of one request. The XML
> fragment can be requested multiple times, but only generated once.
>
> -o-
>
> THE REALLY COOL STUFF
>
> By having the system work in this way, we solve another issue that has
> been plaguing us. How do we create dynamic systems that are easy to
> write and maintain. We have been focusing on using namespaces to mark
> dynamic information like XInclude or ESQL. While they are decent
> develomental tools, practice has shown that they don't scale as well
> when you have to merge information from many datasets. The truth is
> that the person who is writing everything typically will not remember
> 5 different namespace declarations. I personally have to go back and
> copy the XML namespace declarations from other pages.
>
> The callback mechanism allows us to embed events using only one
> namespace for all dynamic logic. We would leverage the development
> effort in Excalibur's scratchpad with the event based architecture
> support systems. The CommandManager processes the actions as they come
> in (with a controlled number of threads that are a function of the
> number of processors on your machine). The interface for the callback
> is simple. We extend the Command interface with XMLSource interface:
>
> interface XMLCallBack extends Command
> {
> XMLSource getFragment( Parameters paramList );
> }
>
> The only thing we have to look out for is the XML event:
>
> <call:event type="newsFlash">
> <call:parameter name="example" value="Business"/>
> </call:event>
>
> We would have to extend the compiled XML to resolve these into one
> callback method like this:
>
> interface CallBackHandler
> {
> event( String type, Parameters paramList );
> }
>
> We kill a number of birds with one stone. We have a natural feel
> for embedding dynamic pieces of generation, while maintaining the
> ability to precompile the XML at each stage of the game. By extending
> the Compiled XML spec to have one more callback type, we defer the
> dynamic portions to controllable classes.
>
> Furthermore, the sitemap controls the pipelines that the XMLSource
> fragments go through. In essence allowing us to precompile those as
> well.
>
> In the end, it is conceivable to go so far as to specify a Compiled
> Stream protocol that has CallBacks. We can explore compiled components
> at just about any level. However, this approach helps solve some
> immediate needs, as well as allows us to use the existing components
> to generate our XMLSources. Hopefully we can explore methods of
> generating CallBack fragments from XSP pages, allowing us to use that
> approach in a more efficient manner.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org