Re: [xmlblaster] Disconnected clients

[Marcel Ruff <ruff at swand.lake.de>]

James Carlyle wrote:
> Marcel
>
> 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

Marcel

> James Carlyle
> http://calaba.com



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