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

Re: [xmlblaster] Disconnected clients

James Carlyle wrote:

Many thanks for your reply.

Both is possible, i would prefer to have one client.
We are working on a redesigned callback framework, which
allows subscription based callbacks (currently the callback
list is setup as a login qos).
This allows to install subscriptions for others - delegate
the subscription setup because of a toaster, a fridge or an email
client may not be intelligent enough to do it himself.

I came across a reference to this idea in engine.qos.login.callback which said "Delegated subscribes: it is possible to subscribe for somebody else to certain messages. This can be handled by logging in again with the callback addresses of that delegated client (kind of gift)". This requirement was marked as "CLOSED". Does this mean that it has been already implemented in the code base? I'm just getting started with Java.

No, not closed, it is marked as Change Request. This is the topic i'm going to implement next. Probably the Change Request is modified to allow specifing such callbacks on subscribe() as well.

The client can set up subscriptions on behalf of a toaster, but the toaster must still have a callback address. I was thinking of what would happen if the toaster could not be called back. Then the single client acting as a proxy for multiple toasters would need to maintain a list of toasters and their subscriptions. I wondered about the correctness of storing a list of first class subscribers in xmlBlaster server, and a list of second class subscribers (like toasters) in the toaster proxy xmlBlaster client.

No problem with this approach.

Has anyone experimented with message forwarding, where an xmlBlaster server instance could be set up to be a subscribed client to another xmlBlaster server instance? Then query evaluation could also be distributed, with the first server doing broad-grained querying and doing a single callback to a second level of servers, which would do more specialised querying, and fan out to more clients.

Smart idea. This somehow correlates with our master/slave cluster idea (see req. engine.replication)

Hope that I'm not asking dumb questions - I'm looking at xmlBlaster in a scenario where the end clients are very thin.

best regards


James Carlyle http://calaba.com

-- Marcel Ruff mailto:ruff at swand.lake.de http://www.lake.de/home/lake/swand/ http://www.xmlBlaster.org