Re: Request for new feature

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

Peter Antman wrote:
> 
> Hi,
> this is a request for a new feature in XmlBlaster. You will have to
> excuse me if this already works, I meen if the feature is already
> available in XmlBlaster, and I have missed it.
> 
> Background:
> 
> Naively I have assumed that the following behaviour was supported by
> XmlBlaster (since it seemded like something any MOM must have):
> 
> - A new client subscriber will only get new messages, not messages
>    published before it logged in and started its subscription.
> 
> Why is this needed? Lets take the following scenario:
> 
> - We have a publisher which is publishing news of some sort. In the key
>  the publisher not only ads a unique oid for every message, it also ad
>  metainformation,such as headline, typ of subject, and perhaps even the
>  body of the text.
> 
> - Clients wants to subscribe to these news, but through an XPATH query.
>   The XPATH query is not placed against the oid since that is unique for
>   every new message, but against the meta info.
> 
> - Only clients that are currently online should get messages that
>   matched their query. A client that goes offline and then comes back
>   should not recive any old messages.
> 
> - A future possibility would be to ad durable subscriptions so that
>   clients that identifyes them self in a special way may get old
>   messages (but not messages they have already recived).
> 
> Current behaviour:
> 
> I have not been able to get this type of behavour to work. Looking
> through the code I get to understand XmlBlaster a little better. To me
> it now seems as if there is a missmatch between the idea of specifying a
> target in the key and specifying searchable metadata. If I get it, the
> basic idea of XmlBlaster here is that messages with new content are
> published to the same key. This is not what I want.

Yes.

> 
> A soulution:
> 
> I have implemented a workaround for this. It might not be the best one,
> but it seems to work. It consists of the following two additions:
> 
> 1. Ad tag <topic> to PublishQoS (a boolean).
> 
> 2. If isTopic is true, then a published message will be removed after
>    publishing in RequestBroker, ie:
> 
>     // NEW FEATURE, Removes message after publishing
>          if (publishQoS.isTopic()) {
>              if (Log.TRACE) Log.trace(ME, "Erasing published message");
> 
>              fireMessageEraseEvent(clientInfo, msgUnitHandler);
>              msgUnitHandler.erase();
>              msgUnitHandler = null;
>          }
> 
> This will only be done i Pub/Sub mode.
> 
> Ok, am I totaly of line here?
> 
> Comments please.

I have added your suggestion, the new publish qos is
called

   <isVolatile>true</isVolatile>

see


http://www.xmlBlaster.org/xmlBlaster/doc/requirements/engine.qos.publish.isVolatile.html

A use case where a published message stays transient (volatile=false)
is for example a mechanical measurement device.
A GUI subscribing to this data wants to see the current
value even if published only every 10 minutes.

thanks,

Marcel


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