[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] Service inteface

Christian Chevalley wrote: 
Hi All,

First, Thank you all for this great piece of code!
Nice to hear that you like it :-)
We are using XB in one of our project for about 2 years now, pretty
successfully. During the development we came across the need for an
extensible service framework, similar to the filter mechanism
implemented, to allow arbitrary handlers of synchronous gets. This
service interface is used to direct synchronous gets to a Plugin
specified in a QuerySpecQoS. It is triggered whenever the key OID is
'_query', hardcoded for the time being like others well-know OIDs. The
plugin is a standard I_Plugin, I_Query implementation. To achieve this,
we patched the RequestBroker and implement a QueryPluginManager class
which is basically a lighter version of AccessPluginManager with a much
simpler logic. The QueryPluginManager is responsible to get/load plugins
as well as maintaining a query plugins cache. As we are doing this for
quite a while now and had to follow up integrating this hack for each
new XB release I am wondering if this contribution is of interest, and,
if yes, how to proceed to integrate this change into the main devel
stream ?
Yes, this is principally possible, your patching to be done is probably not very satisfactory.
But isn't this in conflict with a similar functionality
i just described in the other mail 'HistoryQos with sSQL92 subscrition filters'?

Is your QueryPluginManager directly operating on the I_Queue implementation or
is it filtering after the messages are retrieved (as in RequestBroker.java:1012 of current svn).

The cache functionality: Is it similar to the MIME plugin cache, as for example in
xmlBlaster/src/java/org/xmlBlaster/engine/mime/xpath/XPathFilter.java:220?

If you use the OID as the decision to choose your plugin, this would mean that
the *publisher* decides that the topic is generally using a filter instead of each *subscribe* or *get* accessing client
to decide himself, this is probably a too rigid approach?

Does it make sense to merge the benefits of the two approaches?
Is it possible to port your approach to use our concept or are there missing features?

thanks
Marcel

Cheers,

Christian Chevalley

Austco Communications
http://www.austco.com.au
Phone: +61 8 9244 4499
Fax:   +61 8 9244 4727