Re: Request for new feature

[Peter Antman <pra at mint.se>]

On 23 Feb, Marcel Ruff wrote:
> 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>

Hey, you'r my man! Great. Now I only have to remove my own changes to
get my working copy to work ;-). Volatile was a much better name for the
feature.

By the way, I am on the list now.

//Peter

> 
> 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
> 
> 

-- 
Jobba hos oss: http://www.tim.se/weblab
------------------------------------------------------------
Peter Antman		 Technology in Media, Box 34105 100 26 Stockholm
Systems Architect	 WWW: http://www.tim.se
Email: pra at annons.dn.se	 WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 
------------------------------------------------------------