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

RE: [xmlblaster] Disconnected clients


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.

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.

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.

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

James Carlyle