[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Dyanamic Subscriptions?
Schuhmacher, Bret wrote:
Unfortunately that's not correct. It is currently not possible for a
client to register for such notices.
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?
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.
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.
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.
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!