VOEvent priorities

[Rob Seaman]

On Feb 3, 2010, at 5:43 PM, Andrew Drake wrote:

>> astronomers often include time series in their "telegrams" and VOEvent seeks the capability of representing diverse sorts of such messages.
> 
> Yes, CBAT certainly encourages a reference magnitude or two. However, I highly doubt they would publish the hundreds of points I could send them.

We seek to be capable of representing CBAT content as one (possible) publisher out of many.  (Other considerations control whether or under what circumstances this might ever happen.)

Whether CBAT might want to represent other (VOEvent) publishers' content is their business.

> Likewise, time series data is not very common in ATels since the number of characters one can include is limited.

And we seek to go beyond the limitations of current technologies.  Limits on the length of an ATel need not apply to VOEvent.

> In most cases people tend to refer to external data if people want to include time series or additional data.

This option is already possible for VOEvent.  It seems orthogonal to whether and how one might represent a time series within the packet.

>> However, as chair I'm a little unsure how to respond to a request to revisit a group decision made more than two years ago at HTU-1.  Has something changed to cause us to view the question differently?
> 
> I don't remember this either. Perhaps somebody else will.

http://bit.ly/bPhfzE

> I do enforce VOEvent packet size limit,

What's the limit?

> as do others.

Others please comment.  I recall no such discussions and find that the words "size" and "limit" do not appear in the VOEvent specification.  Pointers welcome.  Perhaps this is a transport issue?  (I don't see anything in the transport note either:  http://www.ivoa.net/Documents/VOEventTransport)

> However, this is a broader question which I thought we may want to consider in the context of large surveys with hundreds of data points per event, thousands of events per night, and hundreds of customers (many of which will likely have slow and unreliable connections).
> Perhaps we could just set some guidelines.

By all means!  Good topic moving forward.

Rob