VOEvent registration: Ha!

[Grégory Mantelet]

Dear Markus,

I comment very quickly as a non expert at all in VOEvent. I've just got 
the impression that VTP is no longer used. As far as I know the 
/continuously updated VOEvent stream/ mentioned in the document makes a 
reference to technologies like Apache Kafka <https://kafka.apache.org/>. 
Maybe people having a better knowledge than me on VOEvent could confirm 
or comment on this.

Cheers,
Grégory


On 04/04/2025 17:22, Markus Demleitner via voevent wrote:
> Dear TD IG,
>
> Thanks to the great people from CHIME, I now have the "reference
> implementation" for a VOEvent registration that I've wanted to make
> at least since VOEvent commit c00365a1 (2020-05-06, almost four years
> ago): It's ivo://org.gavo.dc/std/chime-frb/chime-frb [1].
>
> So, this would be the ideal time for people who know VTP and
> subscribing to VOEvent streams to see whether you can figure out what
> sect. 4.2 of the current VOEvent PR says and whether you succeed in
> the use case "subscribe to all registered and open VOEvent streams"
> -- and if not, what is missing.  I would *dearly* love for that
> experiment to have been made before VOEvent 2.1 goes to REC and we
> can't fix it any more.
>
> During this exercise, I had three, umm, issues; perhaps someone here
> wants to comment on them, too:
>
> * Many VOEvent streams will be of the "continuously updated" type.
>    The Registry currently doesn't really have a way to express that,
>    although the requirement has come up before in other circumstances.
>    I've long thought that this would be most easily reflected by
>    setting a curation/date[@role="utpdated"] in the reasonable future
>    (i.e., ~plausible project lifetime).  I've done this for the chime
>    resource.  Does anyone see anything where that sort of shortcut
>    will hurt us later?
>
> * The record has a stream capability and an archive capability
>    (the latter is just a WebBrowser thing here, but I imagine this
>    could be a TAP service later).  At this point, the fact that that's
>    an archive is not machine readable.  Defining this without a
>    VOResource extension doesn't seem straightforward either:
>    Capabilities don't have a role attribute or something like it.  We
>    could define a standardID, possibly
>    ivo://ivoa.net/std/voevent#browser-archive (then then later perhaps
>    #tap-archive), but somehow this doesn't feel quite right, in
>    particular because "browser-archive" sort of is the opposite to
>    "standard".  Hm.  Is this something that we should sprint to fix or
>    do we delay it to version 2.2 when there actually *are* a few
>    archives people would want to discover?
>
> * To express the location of the VTP endpoint, I have invented the
>    x-vtp URI schema all that time ago.  Do people doubt that's a good
>    idea (frankly: I do)?  And is the host name enough to "open" the
>    stream or do we need a port, too?
>
>
> Thanks,
>
>             Markus
>
> (who would really need a short introduction to VTP and all that's
> related to it)
>
>
> [1] To quickly look at it, use the old trick of prepending
> https://dc.g-vo.org/I/  to it:
> <https://dc.g-vo.org/I/ivo://org.gavo.dc/std/chime-frb/chime-frb>;
> incidentally, that works for all valid ivo URIs.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/voevent/attachments/20250410/e560e57c/attachment.htm>