Hi Mark,

>   - Removed the 'normal' (non-PLASTIC) XML-RPC server that you put in
>     Gaia.tcl.  I presumed this was proof of concept rather than
>     because you wanted GAIA to serve XML-RPC in general, but it
>     can be reinstated if you want.

that's OK, I cannot see any use for this outside of PLASTIC, and it would 
clearly be the way to extend any new services.
 
>   - Updated gaia/library/tclIndex, which I presume is the right thing
>     to do.  

Yes.

>     I haven't added the new classes to gaia/library/Makefile.in,
>     I'm not sure if they're supposed to go in there.

That isn't necessary, but I tend to keep it up-to-date anyway. 
 
>   - I've attempted to follow your style of formatting, variable naming
>     etc etc in the new/modified .tcl files, but have no doubt failed
>     in some places - by all means point out offences and I'll try not
>     to repeat them.

Look's fine to me, seems you haven't forgotten all that Tcl, just yet.
 
> Here's a couple of ways you can see this lot in action:
> 
>    Using starjava PLASTIC package
>    ------------------------------
> 
>    From TOPCAT
>    -----------

All worked as described. Tried to get AstroScope to see it too, but that 
didn't seem to work (could be local difficulties, all those tools don't 
work behind our proxy server).

> So, basic PLASTIC functionality works.  Next steps and queries:
> 
>   - PLASTIC apps ought to inform the hub when they are going to shut down
>     or otherwise stop responding for some reason.  Is there somewhere 
>     I can put tidying-up code which will be executed when GAIA shuts down?
>     This should preferably be invoked even if it shuts down abnormally.

The natural place for this is in Gaia::destructor, but if you want to 
handle abnormal exits, then you'll also need to register what signals you 
want to trap and some procedure to run (I don't do this, so I just expect 
this to work):

   signal trap [list SIGTERM SIGHUP] plastic::cleanup

I'd try to keep plastic::cleanup as a proc in the global scope for extra 
safety.
 
>   - The fits/image/loadFromURL call implementation is a bit of a fudge - 
>     it only works for file:-protocol URLs.  Does GAIA have facilities
>     for loading FITS from a URL rather than just a local file?
>     If not I presume I can find some Tcl library code which will read
>     a stream from a URL which I can save to a temporary file.

That should be possible, I'll go off and refresh my memory about the 
necessary parts of Skycat and extend your method.
 
>   - Obviously, this is only going to be really worthwhile if we can 
>     implement some more, and more useful messages.  There's a 
>     (somewhat scrappily maintained) list of currently defined ones at
>     http://plastic.sourceforge.net/coremessages.html if you're 
>     interested, though there's nothing to stop application authors
>     defining new ones.  In particular:
> 
>        sky/pointAtCoords:
>           Is there a (Tcl-accessible) way of indicating a sky position
>           in GAIA?  This would ideally be some sort of moveable 
>           visible cursor or pointer drawn on the image, but failing 
>           that just warping the zoom window to the right place would
>           be better than nothing.  This function on top of 
>           fits/image/loadFromURL would already make GAIA a worthwhile
>           addition to the PLASTIC desktop.

Yes, that should also be possible, in many ways. We could just draw a 
graphic, or more elaborately fake a table. Any preferences?

>       table-type messages:
>          These currently mostly require VOTable manipulation.
>          I'm considering various approaches to this.

If STILTS supported TSTs then GAIA could be extended to use tablecopy as 
another filter (this is how it handles any of the CAT supported formats) 
and convert any VOTables into TSTs. That would be cheap, if somewhat 
nasty.

>   - [Eventually] There are issues with converting between (typeless)
>     Tcl variables and (typed) XML-RPC elements that I have to look into.
> 
>   - [Eventually] There probably wants some to be some GUI at some
>     stage to control registering/unregistering with the hub etc -
>     cf TOPCAT's Interop menu
>     (http://www.starlink.ac.uk/topcat/sun253/plasticControl.html)

I'd guess that would be reasonably straight-forward.

>     Not to mention getting GAIA to make requests to other PLASTIC 
>     applications.

Indeed, from our perspective SPLAT is an obvious target, I guess TOPCAT 
might be for more sophisticated catalogue handling and visualisations.
 
> Finally: how can I run GAIA during development without deleting and
> remaking gaia_swish (slow)?  If I've just edited a couple of lines 
> in one of the Tcl files I don't know how to start up GAIA in such 
> a way that it notices I've made a change.  I presume there must be a way!

Yes, you do all the work in the gaia/gaia tree, after an initial full 
build (assuming you're in applications/gaia):

  % cd gaia
  % ./devlinks
  % cd library
  % setenv GAIA_DIR `pwd`
  % setenv GAIA_LIBRARY `pwd`
  % ./tgaia &

will pick up all the scripts from the library directory, so just edit them 
and restart "./tgaia". "$GAIA_DIR/tgaia", works from elsewhere. The 
"devlinks" script just needs to ran once, until you clear out the 
checkout.