On Wed, 26 Jul 2006, Peter W. Draper wrote:
> > and also send the current image to other PLASTIC listeners who care
> > about images, either by Broadcast to all or by sending to a single one.
> > For FITS this seems to work fine.
>
> this too, I managed to send an image to Aladin, but the reverse didn't
> work (I suspect the number of dots in the cached image name is causing the
> problem). Bizzarely GAIA responded to pointAtCoords messages from
> Aladin... That expected?
Unless I'm missing the point of your surprise, yes this is exactly
the sort of thing that is expected - pointAtCoords is one of the
"standard" PLASTIC messages, and Aladin broadcasts it when it
thinks it's sensible to do so. GAIA knows what the message means
and responds in the way it sees fit. An important part of the PLASTIC
philosophy is that applications can benefit from sending/receiving
such standard messages without any special arrangements having
to be made between the authors of the tools in question.
> > For non-FITS the strategy is to write a temporary FITS file,
> > send the loadFromURL message, wait for success/failure returns from
> > all applications, and then delete the temporary file.
> > This is analogous to how TOPCAT sends tables around using PLASTIC.
> > This isn't currently working, and it may be because you can't write
> > non-FITS files to FITS, though code/comments in GaiaImageCtrl leads
> > me to believe that you ought to be able to. Anyway, could you have
> > a look in PlasticSender.tcl where this happens and comment and/or
> > hack as appropriate?
>
> OK, done that. I expect you didn't have CONVERT initialised (you have to
> do that by hand when in development mode, normally the gaia.csh script
thanks - should have thought of that.
> does this). There were some other issues I've fixed up too. Presumably we
> could look at supporting some loadFromUrl#ndf message for Starlink apps?
Yes we can, though I've expressed in earlier messages slight reservations
about transmitting images in non-FITS format. Internal use for Starlink
is unobjectionable though. However, the message would not
be ivo://votech.org/fits/image/loadFromUrl#ndf, but a new one,
maybe ivo://starlink.ac.uk/ndf/loadFromUrl. Apart from the
obvious fact that the existing one has the word "fits" in it, I don't
think this is quite the sort of thing that the idea of "subclassing" a
message by adding a fragment identifier is supposed to do, since
the frag id is not supposed to convey machine-readable information,
and for this case the software needs to know whether the data is
FITS or NDF in order to process it (also to determine whether it's able
to do so).
> > Some other things which I still need to tidy up are:
> >
> > - It's too verbose on startup when the hub is not present (as discussed)
> >
> > - Probably some of the error messages which are currently getting
> > puts'd should turn up in popup windows instead.
>
> Started that trend.
I've made some more improvements. Now, on startup it checks whether
it looks like a hub is running (whether ~/.plastic exists) and only
if it does will it try to register.
The effect is that for most users with no hub running, GAIA will start
up with no more verbosity than they're used to, though they will see
the new Interop menu. For users with a PLASTIC hub running, who
presumably won't get too confused by this, they'll get a short message
like:
Started XML-RPC server for PLASTIC at http://andromeda.star.bris.ac.uk:8025
PLASTIC service at http://andromeda.star.bris.ac.uk:8025/plastic2387
Only users who have a broken .plastic file (not common) will see an
error message on stdout.
If you subsequently attempt to register from the Interop menu, you
either get the short message on stdout for success, or a popup with
the error message for failure (e.g. no hub running).
I'd say this is reasonable behaviour for both PLASTIC and non-PLASTIC
users, however if you want to tweak it (e.g. hide Interop menu unless
it's specifically enabled on the command line) then by all means
hack away or tell me what you want and I'll do it.
> > - I probably want to scan for ports when starting up the XML-RPC
> > server in case the default one is taken. If nothing else this
> > would facilitate testing by being able to bounce messages
> > between two running instances of GAIA (the only other PLASTIC
> > app with image-friendly capabilities is Aladin, and I'm having
> > a bit of trouble getting that to run well just now, not sure
> > if it's bugs or what).
>
> As I said Aladin worked for me, although I too would have liked to be able
> to send to another GAIA instance as well.
Now scans for ports so you can run multiple PLASTICated GAIAs at once.
They seem to send images between each other happily.
> > Apart from that it might just be possible to sneak simple
> > catalogue-tranfer facilities in before the end of July. A TST
> > backend to STIL shouldn't take too long, and the infrastructure for
> > sending/receiving messages in general is all(?) in place now.
> > I had initially been thinking along the lines of JNI or
> > client/server type IPC for translating between TST and VOTable,
> > but I suppose there's no reason that I can't just check if stilts
> > is on the path and exec it to do the translations (is this the
> > GAIA way?). Not very elegant or very efficient, but better
> > than nothing, at least for starters. Done that way I presume
> > there wouldn't be a lot of work in the GAIA code to implement
> > table send/table receive - do you agree?
>
> Yes, just exec the call to tablecopy (see the GaiaForeignExec class, that
> is used for forking non-ADAM programs). We can also add this as a filter
> to GaiaConvertTable, so that local VOTable can be loaded and saved too,
> but that will take a bit of recoding.
>
> > Unfortunately (well, depends how you look at it) though, I'm on
> > holiday Mon-Wed next week, back Thurs, so time might be a bit tight,
> > we'll have to see.
>
> The news gets worse, I'm on holiday from the end of the week, for two
> weeks, so whatever we need to do must be in place by the close of play on
> Friday. That makes it sound like we need to feature freeze now and
> concentrate on the merge to the main branch. If you agree I'll do the
> merge tomorrow.
Oh dear oh dear GAIA's never going to be a VO-era application with
a development philosophy like that. Finalising functionality on
the plane on the way to the meeting where it gets demo'd should
give you plenty of time for testing.
But seriously. I'd say it's in a sensible state for a merge now.
I think there's a fair chance (80%??) I could add load catalogue
functionality (i.e. respond to ivo://votech.org/votable/loadFromURL)
by the end of today, so if you wanted to wait until tomorrow for
the merge we might have more there. However I wouldn't want to put
the robustness of the release at risk (or get your holiday off to
a bad start), so I'll leave this call up to you.
Oh, I don't know how documentation works in GAIA by the way; I haven't
added any for the new features. In practice, it's likely that most
people who want to use it will have a clue what it's about already,
but I suppose there may be curiosity about what the new menu does.
If you want me to write something, point me at where the docs live
and I'll write something of appropriate verbosity. If you want to
do it, I should think the main thing would be to put in a link to
http://plastic.sourceforge.net.
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|
