> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> > > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
> > >
> > > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
