Re: [xmlblaster] Dyanamic Subscriptions?

[Michele Laghi <laghi at swissinfo.org>]

Hi Bret,

Schuhmacher, Bret wrote:
> How's the best way to handle this?  I'm trying to allow clients to subscribe
> to OIDs, but I don't want them to have to know about them in advance.  This
> will allow new publishers to just start publishing without any client setup.
>
> I was looking through the docs and I see that it's possible to query the
> engine for the available OIDs via ?topicList.  It also appears possible for
> clients to register for notices when this list changes - is this correct?
Unfortunately that's not correct. It is currently not possible for a 
client to register for such notices.
However there are different ways to get there:

Dirty Hack: Retrieve the topic list synchroneously with a get from time 
to time. This is the very fast solution.

Hack: Write a mime plugin (publish plugin) which analizes all published 
messages. If a message is new (a new oid), then the interested client is 
notified. On initialization the plugin would subscribe to a certain oid 
(lets say "requestTopicListChange"). For a client to register for 
notification it would then be necessary to publish a message with the 
oid "requestTopicListChange". In the content of the message you could 
send application specific information. This is the fast solution.

Clean Solution: Implement in the xmlBlaster core a generic "internal 
event to message mapping", that is, define some important events which 
could be of public interest. Define the listener- & event interfaces 
(for example I_InternalEvent and I_InternalEventListener), implement the 
places in the core where these events have to be triggered and finally 
implement the plugin. This plugin would implement the 
I_InternalEventListener and it would map the events to messages. In 
other words it would send messages to the interested clients. In this 
case clients would subscribe to receive such events as messages.

This last solution has been on the developers whishes list for quite a 
while. If you have time to wait we will provide this solution soon or 
later (don't just know when). If you don't want to wait and feel willing 
to implement it we could provide you with further design details.

> If so, would it be possible for a client to query the engine for the
> available OIDs and register to get changes to this list, then subscribe to
> the OIDs in the return message?  It looks like it.  However, what happens
> the first time a publisher sends a new message?  The client hasn't been
> informed about it and will likely miss the first message, won't they?  The
> first message will cause the engine to alert the client that a new message
> exists, won't it?  So after the first message the client should get the
> updated OID list and subscribe to the new topic, but the first message will
> likely be missed.
As a default behaviour, when subscribing a message you will get the last 
update even if the publish took place before your subscription, so this 
is not a problem here.

> My alternative isn't quite as dynamic.  I was going to have clients send a
> message to a database manager who's listening for OIDs like "CONFIG" or
> something.  The db manager would hit a database and return a list of
> messages the client is allowed to subscribe to.  The client can then
> subscribe to those messages.  This alternative requires prior setup when you
> want to institute a new publisher (or a new OID, anyway).
>
> Is there a "best practice" for this kind of thing?
>
> Thanks in advance!
>
> Bret

Saluti
Michele