VOEvent II summary, part 3

[Rob Seaman]

Hi Andrew,

>> Pull:
>> 	RSS 2 with enclosures.  We'll undoubtedly have more to say about  
>> this choice after we gain more experience.
>
> Although I like the idea of enclosures I intend to use both links  
> and enclosures as most rss feed readers do not fully support  
> enclosures.  For instance the rss reader that I currently use. I  
> expect many people will already have their favorite rss readers set  
> to receive various feeds and may be reluctant to change.

The other guys can comment, but the whole tenor of the conversation  
was to allow freedom of transport - at least for the near to medium  
term.  If you don't want to use enclosures, nobody is going to force  
you to.  The packets themselves may be riddled with external  
references, or may be replaced completely through indirection.   
Enclosures are more in the nature of a goal to pursue.  I probably  
didn't emphasize the point enough, but several groups will continue  
to investigate other transport protocols.  Ultimately we're simply  
going to need reliable messaging.

We should also continue to distinguish between communication  
protocols extending outward to our users (authors and readers) and  
those used internally between brokers.  Since the summer school I've  
tried to infect the discussion with the "SEAP" meme.  What language/ 
interface/protocol is used to provide "Simple Event Access"?  But  
this effort has proven pretty unsuccessful.  We need to bootstrap a  
broadly based functional network before we have an opportunity to  
standardize the technology.  Even then it may not be obvious that we  
will want to do so - as that neo-Bolshevik Alasdair says, the market  
will decide.

>> 1) An ack message:
>> 	Upon successful receipt of a packet, the receiving component will  
>> return an ack packet to the sender.  At its simplest, this will be  
>> an empty VOEvent element:>
>> 		<VOEvent id=<same as original packet> role="ack" version=... />
>> An ack packet might also contain normal VOEvent content, but this  
>> is discouraged until we come up with a good reason for doing so.
>>
>> 2) An "I am alive" packet:
>> 	On an arbitrary schedule(s), each broker emits role="iamalive"  
>> packets to other brokers (meaning other VOEvent participants,  
>> perhaps including individual subscribers).  Subsequent discussions  
>> have clarified the format of these packets to include a timestamp  
>> and explicit publisher ID:
>>
>> 	<?xml version = '1.0' encoding='UTF-8'?>
>> 	<VOEvent role = "iamalive" id = "ivo://talons.lanl/001" version =  
>> "1.1">
>> 	    <Who>
>> 	        <PublisherID>ivo://talons.lanl</PublisherID>
>> 	        <Date>2005-12-11T01:10:03</Date>
>> 	    </Who>
>> 	</VOEvent>
>
> I take it that we are sending the first line here to make even the  
> imalives valid xml docs (this must be in the acks too then).

Right - sorry for the omission.  Expect the attendees will find other  
garbled examples.  Doubt we have to belabor the desirability of  
exchanging conforming XML.

> I would be in favor of keep imalive packets as short as possible  
> since we are sending equally long replies to every connection in  
> this scheme. It seems to me, as we are keep the connections open,  
> most of this information can be obtained straight from the  
> connection without any <Who> element.

The best argument for encoding the timestamp(s) within the packets is  
to minimize the state that each broker is required to keep track of.   
One could use an ack to serve both purposes, but then the receiving  
broker needs to determine why a particular ack is arriving.  Is it a  
response to a prior transmission or is it simply a joyous assertion  
of life from a colleague?  On the other hand, one could argue for  
including a timestamp within an ack, but the case for minimizing the  
size of each ack is much stronger.  Ideally we will reach levels of  
usage in which acks occur orders of magnitude more frequently than  
iamalive packets.

We chose to embed each packet's timestamp within <Who> to benefit  
from the RM efforts.  I suspect few of us would want to revisit that  
decision at this point.  The <Who> element also conveys the  
<PublisherID>.  This permits distinguishing packets derived from  
external brokers from self-packets, for instance.

I'd be interested in any details you have of obtaining timing  
information "straight from the connection".  We definitely need to  
look at prior art here before settling on the next version of the spec.

It also seems likely that the iamalive mechanism will find use under  
more robust transport mechanisms, too.  We've run into the need for  
similar end-to-end delivery confirmation within archival data  
transport streams.  An ack is likely a detail of a particular  
transport mechanism.  An iamalive is a reality check on the health of  
the endpoints of the conversation - a means for building confidence  
that when an alert does occur that the message will be heard.

> I thought we were changing the id element in VOEvents, but I'm  
> probably mistaken.

No, simply haven't had a second to think about what to call the new  
attribute.

Thanks for playing the home game!

Rob