GCN & VOEvent Parser/Writers (inital pre-release)

Alasdair Allan aa at astro.ex.ac.uk
Fri Apr 22 09:38:53 PDT 2005


Joshua Bloom wrote:
>    You might consider getting a public CVS repository up, rather than 
> having to aggregate all of the tweaks that we'll inevitably want to 
> perform. This is a great start and you should let some of the 
> community help you out at this point.

It's in the eSTAR CVS server at Exeter, it's not public at the moment, 
but that's fixable. Although I'm just about to leave for the weekend so 
not at the moment!

>  If you're interested we could add this to the pygcnsock project on 
> sourceforge.

I'll probably prefer to leave it where it is, although I hadn't 
separated the code out the GCN module at least is already part of the 
core eSTAR build, and I don't really want to have to keep track of 
another module on yet another 3rd-part-CVS-server (I do too much of 
this already)

I'll take patches over the weekend, and put it on a public CVS server 
some time next week.

The obvious to do's are,

Astro::GCN
    - support of something other than the bare bones SWIFT packets
    - a test suite (whoops, really should have written one)

Astro::VO::VOEvent
   - convenience layer ontop of the build() functionality, an accessor 
method per main section tag perhaps?
   - convenience methods ontop of the parse() function which currently 
just returns an DOM tree (yuck!)
   - some more flexibility in build(), but not before adding some 
convenience functions. It's too hard to construct a document at the 
moment already!

gcn_server.pl
   - the current barebones implementation needs more functionality in 
the tcp_callback(). Even with the current state of the 
Astro::VO::VOEvent module it could do a lot more stuff here!

Cheers,
Al.



More information about the voevent mailing list