VOEvent II summary, part 3

[Alasdair Allan]

I'm now basically compliant with what we discussed at the mini-interop, 
or at least I think so, see below for details...

I've just released the current version of the "ready-for-the-public" 
branch of my Perl Module for parsing and building VOEvent packets to 
the Sourceforge site voevent.sourceforge.net, the latest version of the 
module is release 0.6. Also on the site is a very basic Perl module for 
handling GCN packets, and a skeleton GCN server.

The Perl module now handles both STC and Simple representations of 
<WhereWhen>. Although on the build side the message format might not 
exactly comply with the most up to date standards document as I haven't 
verified them recently.

Rob Seaman wrote:
>  Andrew Drake wrote:
>> Rob Seaman wrote:
>>> 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.

As agreed in the mini-interop I've moved from Atom to RSS 2.0 with 
enclosures, the combined eSTAR & TALONS GCN feed can now be found at  
http://www.estar.org.uk/voevent/gcn.rdf although my FeedBurner
translation is still at  http://feeds.feedburner.com/EstarTalonsGcnFeed.

If you want to follow the combined feed without being interrupted by 
development process, you should probably subscribe to the FeedBurner 
feed as the URL will be static, unlike the development feed coming out 
of eSTAR.

I agree with Andrew, I'm using both links and enclosures. Links for 
humans,  enclosures for (asynchronous) programmatic access to the feed. 
I think the enclosures are important for programatic access, that's 
what they're designed for after all...

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

RSS and TCP were the things everyone should implement, you're feed to 
offer different protocols, we've all bee tasked to look into 
alternatives.

> We should also continue to distinguish between communication protocols 
> extending outward to our users (authors and readers) and those used 
> internally between brokers.

You think the "VOEvent Backbone" should standardise on a single 
protocol? Makes sense, but I think you're going to be disappointed in 
the short/medium term, it's probably going to be raw TCP.

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

No I agree, I think the backbone will eventually need some sort of 
reliable messaging protocol, but I've got a funny feeling we'll be 
rolling our own rather than going with something standard. Some of the 
stuff we want to do is interestingly weird enough that the standard bag 
of higher level protocols might not fit exactly what we need.

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

Indeed! Long live the revolution...

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

Absolutely these are real XML messages. All of them!

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

Agreed. Robert and I are in the middle of implementing the current 
IAMALIVE proto-specification, I've just done my half and I'm waiting 
for the States to wake up for Robert to finish his end. Should be 
working by the end of the day west coast time.

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

An IAMALIVE is not just testing the connection, it's testing the 
software at each end, up to an including that software's DB etc. The 
complicated bit of software generating a IAMALIVE message should do 
some sanity checks before sending it, to verify it really is alive, 
correspondingly a bit of software receiving an IAMALIVE should actually 
do some sanity checks before replying, to make sure any messages it 
gets won't vanish down a black hole.

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

Oh, the id problem. That's an angle bracket problem, not really 
relevant. Although we need a collective decision here since a few of us 
now have actual parsers that are going to break when we make the 
change, what we actually change it to isn't really very important.

Cheers,
Al.