On Mon, 14 Aug 2006, Tim Jenness wrote:
> > I've checked this lot into CVS on the trunk. Since the keoe deadline
> > was a couple of weeks ago I presume it's too late for that, though
> > I do recall Tim commenting that the schedule had been put back a bit...
> We are now in testing week again since Brad is now back and working full
> time on the release. On the assumption that this only touches PLASTIC code
> then it seems prudent to integrate it into the keoe branch since that will
> make it easier for you to do demos.
I was simultaneously hoping and fearing that you'd say that.
From the point of view of getting the PLASTIC-capable version
(catalogues included) onto the desktops of users who might want
to use it, as well as ease of demoing, it would certainly be
nice to get it into keoe. I don't know when your next release
after that is likely to be, but I presume not all that soon.
However there are a few things that make me slightly nervous about
merging the new features onto the keoe branch:
- I haven't yet done very extensive testing of the new features,
and there are rather more usage pathways in the catalogue-
related features than the image-related ones that are already
in keoe. If we merge though I'll certainly give it more of
a working over in the immediate future.
- As noted in some of my previous messages I can imagine some
things that could cause problems during use of the new
features, e.g. sending subsets from a very large catalogue
(very slow, and blocking). There may be things I haven't
- Peter hasn't had a look at the new code yet. Although I don't
think I've done anything grossly stupid, it might be prudent
for him to run his eye over it before it becomes part of the
- It may be that the design of the user interface could be done
better, and that I/we might think of better ways of presenting
some of the functionality after playing with it a bit (I've
already had one or two thoughts). Of course, this sort of
thing would be helped out by some user experiences, which in
turn will be easier to come by with a public release including
some form of the new functionality.
- Although I believe that in the absence of a PLASTIC hub
my changes won't make any difference to the rest of GAIA,
there was that funny where you had cube load crashes that
appeared to go away when I fixed something I thought was
specific to the PLASTIC classes. So there may be some
possibility of non-PLASTIC trouble introduced by the new code.
To summarise, I think there are mild risks if we add the catalogue-related
code into keoe of a GAIA release that is slightly flaky in the
presence of a PLASTIC hub and that presents PLASTIC features which
will or should undergo some redesign in future releases. Whether you
think these risks are worth the benefit is down to you and Peter
really - for my purposes I would like to see the new features on
users' desktops without having to wait for another JAC release cycle,
but I've got less invested in GAIA's reputation for robustness,
so I wanted to put my concerns up front.
A compromise might be to add it all in but mark it as "experimental
functionality". This could perhaps be reinforced by turning the
PLASTIC features off by default (set $itk_option(-interop_menu) 0),
so people are only exposed to them on explicit request.
Let me know what you both think - I'll merge the trunk classes to
the keoe branch if you still reckon it's a good idea.
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/