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