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

Re: [xmlblaster] Dyanamic Subscriptions?

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!


Saluti Michele