VOEventNet is more than a transport protocol

[Rob Seaman]

On Dec 26, 2011, at 11:17 PM, Bob wrote:

> (1) Is "transport neutrality" like "gauge neutrality" for a railroad?

Henry Petroski touches on railroad gauges in his "Success through Failure", but also in other books.  The two mentioned in #1 are similar in that they are a product of engineering evolution.  They are dissimilar in that railroad gauge was ultimately inherited from the ruts left by ancient Roman wagons.  Breaking out of the weakly analogous transport paradigm was, for instance, the challenge faced by the IAU telegrams, not VOEvent.

> (2) Is "undefined and ever expanding incompatible transport" standing in the way of adoption? I suspect the uncertainty is a huge barrier to adoption.

This is a "complex question" ("plurium interrogationum" if any of those Romans are listening in).  The transport note provides a definition.  "Ever expanding" assumes that things like Elvin don't naturally die out.  "Incompatible" presupposes that bridges don't exist, whereas a precondition of deploying a new transport option on the VOEventNet is precisely that a compatible bridge exists.  Uncertainty is indeed to be avoided, which is why we've handed out 700 copies of the Hotwired book (and more for the upcoming AAS).  A book BTW containing Bob's chapter that describes connecting to the VOEvent backbone using Dakota and vTCP.

> (3) Ah, the LSST spectre... I say again "Who is going to USE (or even LOOK AT) 2 million alerts per night? What's the point?

This is backwards.  Using the full firehose requires precisely that nobody be required to look at them.  This naturally leads back to all the functions of the VO and astroinformatics.  Few projects will subscribe to the full feed.  Many users will subscribe to filtered streams that provide only the brightest events, for instance.  Such requirements will have contingent implications for future transport technologies - or perhaps all the smarts should be built into the clients and servers?  Should we really limit our design conversations a priori?  We provided vTCP as the baseline for the backbone precisely with the understanding that no filtering occurs on the backbone.

At any rate, growing the backbone is a separate activity from the tier-two delivery of alerts (and related content) to endusers.  This also is discussed in Bob's chapter of the Hotwired book, where I believe the word "Jabber" is mentioned.  Might zeromg replace jabber for this use?  Are such discussions not within the remit of this group?

> It seems like the stick that the sandboxers use to beat the realists over the head with. That head again ;-)

I'm not entirely clear what is meant by "sandboxer", but presumably it is intended to imply "non-realist".  Also not clear how: 1) discussing future transport options is a stick, and 2) how the heads of those who have very realistically written code and deployed services against the transport note are threatened.

> (4) Is transport research and development for VOEvent a vehicle for garnering additional grant (and therefore grocery/housepayment) money? If so, stability and adoption are hopeless.

Stability and adoption have been happening steadily since 2005.  VOEvent has been remarkably successful at the rather daunting challenge of providing an evolutionary path for a community activity that predates the IAU itself.  I am unaware of any prior celestial event report project that we have not engaged with - and sought to breathe new life into.  Similarly we are engaged with future time domain projects, both surveys and follow-up telescopes.  We are lucky to have a bit of breathing room between the successes of the past and those of the future to plan and build.  Not surprisingly, especially in this economy, bootstrapping the deployed network of brokers is proceeding through stages.

The short answer to question #4 is "no".  The longer answer would be off-topic for this mailing list.

Rob