plastic-devs Mailing List for PLASTIC (Page 4)
Brought to you by:
johndavidtaylor,
thomasboch
Menu
▾
▴
plastic-devs — Plastic Developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
(11) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
(110) |
Mar
(36) |
Apr
(55) |
May
(42) |
Jun
|
Jul
(42) |
Aug
(14) |
Sep
(34) |
Oct
(7) |
Nov
(35) |
Dec
(5) |
| 2007 |
Jan
(3) |
Feb
(5) |
Mar
(18) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(27) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John T. <jon...@gm...> - 2006-11-17 17:26:55
|
Hi again Ray, Ray Plante wrote: > Hi John, > > On Fri, 17 Nov 2006, John Taylor wrote: > >> First up, apologies for the delay in replying to this. There is A Reason >> behind the choice of ivoids as messages. They're meant to be unique, so >> using a URI seems to be reasonable. Why a registry URI? Well, we think that >> there could be a benefit in registering the messages as separate resources. >> > > I believe you can do all of this with the syntax I recommended, e.g. > > ivo://votech.org/plastic#info/getIVORN > > That is, you would be able to: > o search the registry to discover the meaning of this message > o search the registry for applications that support this message > o have a tool interogate the registry to build a GUI for the message > > These capabilities would rely on: > o there being registered a Plastic resource, of type "Standard" where > the messages are defined. > o there being tools that register their support for the messages > (say as capabilities). > It's certainly an alternative worth considering, though I see two problems: 1) we're already using the #fragment for something else 2) it centralises the definition of messages in one place - we want to avoid this. So far all the messages have been defined "with the votech.org authId" (bad bad choice), but I'd really like to see ivo://estar.org/voevent/do/something/funky appear at some point. Now we'd be crazy to let Alasdair get his hands on our publishing registry...so how would he add his message to the master list? > The motivation for this alternative is to preserve two principles consider > very important: > o that you can, via a registry, dereference an IVO ID to a > description. > Sure, I admit that it's a rather strange wrinkle if we don't end up registering them. But... ivo://surely ivo://you/dont ivo://claim/ownership of those 6 little letters? The message strings themselves will by and large be invisible to users so shouldn't really cause any confusion. > o that the registry focus on course-grained resources, so that > + we control the rate of growth of the registry, thereby > controling the performance and maintanence costs > We're not talking about very many here in the grand scheme of things. If you can detect a measurable drop in performance in your registry I'll buy you a pint and some extra memory out of my next pay packet. OK, I know, I know, it's the principle...if every tin pot little project starts doing this we could be chest deep in VOResources before we know it. > + we not confuse end users with a vast number of resources that > are rarely of interest to them > I reserve comment on that one! > + we not replicate the information content that is better managed > by local providers and accessed through 2ndary services (e.g. > SIA) (This point is item is less relevent to the plastic > issue.) > Well, as you know, there are differing opinions on whether service metadata is better accessed from the registry, the service or both. > hope this clarifies things, > It does - I hadn't thought of the approach you suggested. John > Ray > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs > > |
|
From: Ray P. <rp...@po...> - 2006-11-17 17:04:13
|
Hi John,
On Fri, 17 Nov 2006, John Taylor wrote:
> First up, apologies for the delay in replying to this. There is A Reason
> behind the choice of ivoids as messages. They're meant to be unique, so
> using a URI seems to be reasonable. Why a registry URI? Well, we think that
> there could be a benefit in registering the messages as separate resources.
I believe you can do all of this with the syntax I recommended, e.g.
ivo://votech.org/plastic#info/getIVORN
That is, you would be able to:
o search the registry to discover the meaning of this message
o search the registry for applications that support this message
o have a tool interogate the registry to build a GUI for the message
These capabilities would rely on:
o there being registered a Plastic resource, of type "Standard" where
the messages are defined.
o there being tools that register their support for the messages
(say as capabilities).
The motivation for this alternative is to preserve two principles consider
very important:
o that you can, via a registry, dereference an IVO ID to a
description.
o that the registry focus on course-grained resources, so that
+ we control the rate of growth of the registry, thereby
controling the performance and maintanence costs
+ we not confuse end users with a vast number of resources that
are rarely of interest to them
+ we not replicate the information content that is better managed
by local providers and accessed through 2ndary services (e.g.
SIA) (This point is item is less relevent to the plastic
issue.)
hope this clarifies things,
Ray
|
|
From: Doug T. <dt...@nr...> - 2006-11-17 16:27:08
|
On Fri, 17 Nov 2006, John Taylor wrote: > I guess we're always going to have a tension between a language tuned to a > particular tool and able to expose its full power, and something more > general. Probably the key distinction is an interface which simply allows one to "drag and drop" a structured data object onto a tool, and an API used to interactively control or drive a particular tool. Both have their place. PLASTIC seems to be mainly of the "drag and drop" variety. >> When a language becomes rich >> enough one would probably prefer to register the namespace or schema >> for the language, not the individual elements of the language itself. >> > Interesting. I wonder whether it's feasible for us to aim at rich languages > rather than very simple operations, given the cross-organisation nature of > the endeavour. Perhaps I'm being unambitious. Another way to think of it is, if a component exposes an API, we generally want to register a WSDL or some such specification for the API, rather than the individual elements of the API. Perhaps PLASTIC is not a general messaging system at all, capable of exposing stateful APIs or passing general events, but rather a type of object-oriented drag-and-drop mechanism? Is it mostly used to "push" data objects at tools? - Doug |
|
From: John T. <jd...@ro...> - 2006-11-17 16:07:51
|
Doug Tody wrote: > Hi All - > > In thinking about where this sort of inter-tool messaging might go in > the future, it might be useful to look into the past, for example the > messages which have been defined for the ds9 image display client (which > uses XPA as the underlying messaging transport). See for example > > http://hea-www.harvard.edu/RD/ds9/ref/xpa.html Thanks for this reference - I'm hoping that it won't be beyond us to fashion some kind of plastic-xpa bridge, even at this early stage. I'm sure there's a lot we can and should learn from the way ds9 messaging works. > > One might conclude that messages of this sort can be viewed as a > language, defined separately for each type of tool, based on the types > of data and operations it deals with. I guess we're always going to have a tension between a language tuned to a particular tool and able to expose its full power, and something more general. At the moment we've concentrated on very general messages, although we've toyed with the idea of exposing the full Aladin scripting interface through Plastic. There's probably room for both, though you get a bit tangled up when you have several messages that essentially do the same thing. > When a language becomes rich > enough one would probably prefer to register the namespace or schema > for the language, not the individual elements of the language itself. > Interesting. I wonder whether it's feasible for us to aim at rich languages rather than very simple operations, given the cross-organisation nature of the endeavour. Perhaps I'm being unambitious. However we do this, my feeling at the moment is to keep the messages fairly short strings, rather than (say) going down the route of making them xml. This keeps plastic simple enough to use from the command line in Python. As for namespacing, one of the benefits of using ivoids was that we get namespacing through the authorityIds. At the moment this is purely for the human's benefit - as far as an app is concerned the messages are opaque strings and no plastic app can infer that ivo://votech.org/.../votable/loadFromUrl is related to ivo://votech.org/../votable/showObjects . John > - Doug > > > On Fri, 17 Nov 2006, Roy Williams wrote: > >> John >> >> Following your logic, this means that VOEvents can also be registered >> individually, rather than registering the server that handles them, >> as Ray suggests. I understand that LSST will be putting out thousands >> of event notices every night. Do you think the VO registry system >> will be able to handle the load? >> >> Another problem is inflexibility. Suppose a group wishes to >> experiment with their own dialect of messages, and they want to >> change rapidly, adding and deleting. In the official (Ray) scheme, >> they would have a standalone message registry that may or may not be >> registered with the VO registry. In your scheme, each message is >> added and deleted from the entire global VO registry. >> >> Of course it is much more convenient to have "everything in the >> registry", it is a one-stop shop instead of a two-stage process. But >> perhaps not always the best solution....... >> >> Roy >> >> >> >> John Taylor wrote >>> a search of the registry reveals the ivo://..../loadVOTable message >>> >>> Ray Plante wrote: >>>> Instead, I would recommend the approach that is to be used by the >>>> VOSpace standard in which names are identified using a # suffix; e.g., >>>> >>>> ivo://votech.org/plastic#info/getIVORN >>> >> > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: John T. <jd...@ro...> - 2006-11-17 15:49:45
|
Reposting....
-------- Original Message --------
Subject: Re: illegal/unrecommended use of IVOA identifiers
Date: Fri, 17 Nov 2006 08:40:18 -0700 (MST)
From: Doug Tody <dt...@nr...>
To: Roy Williams <ro...@ca...>
CC: John Taylor <jd...@ro...>, Ray Plante
<rp...@po...>, pla...@so...,
reg...@iv...
References: <Pin...@po...>
<455...@ro...> <455...@ca...>
Hi All -
In thinking about where this sort of inter-tool messaging might go in
the future, it might be useful to look into the past, for example the
messages which have been defined for the ds9 image display client (which
uses XPA as the underlying messaging transport). See for example
http://hea-www.harvard.edu/RD/ds9/ref/xpa.html
One might conclude that messages of this sort can be viewed as a
language, defined separately for each type of tool, based on the types
of data and operations it deals with. When a language becomes rich
enough one would probably prefer to register the namespace or schema
for the language, not the individual elements of the language itself.
- Doug
On Fri, 17 Nov 2006, Roy Williams wrote:
> John
>
> Following your logic, this means that VOEvents can also be registered
> individually, rather than registering the server that handles them, as Ray
> suggests. I understand that LSST will be putting out thousands of event
> notices every night. Do you think the VO registry system will be able to
> handle the load?
>
> Another problem is inflexibility. Suppose a group wishes to experiment with
> their own dialect of messages, and they want to change rapidly, adding and
> deleting. In the official (Ray) scheme, they would have a standalone message
> registry that may or may not be registered with the VO registry. In your
> scheme, each message is added and deleted from the entire global VO registry.
>
> Of course it is much more convenient to have "everything in the registry", it
> is a one-stop shop instead of a two-stage process. But perhaps not always the
> best solution.......
>
> Roy
>
>
>
> John Taylor wrote
>> a search of the registry reveals the ivo://..../loadVOTable message
>>
>> Ray Plante wrote:
>>> Instead, I would recommend the approach that is to be used by the VOSpace
>>> standard in which names are identified using a # suffix; e.g.,
>>>
>>> ivo://votech.org/plastic#info/getIVORN
>>
>
--
------------------------------------------------------------------------
AstroGrid/VOTech
&
WFAU, Institute for Astronomy, Edinburgh
Skype:johndavidtaylor <skype:johndavidtaylor?chat>
------------------------------------------------------------------------
*Gratuitous advertising:*
Plastic - http://plastic.sourceforge.net | AstroRuntime -
http://www2.astrogrid.org/desktop
AstroGrid - http://www.astrogrid.org | WFAU -
http://www.roe.ac.uk/ifa/wfau/
|
|
From: John T. <jd...@ro...> - 2006-11-17 15:07:13
|
Sorry to post this twice, but I wanted to correct the mistaken plastic devs address in the cc line before more people replied. > > ------------------------------------------------------------------------ > > Subject: > Re: illegal/unrecommended use of IVOA identifiers > From: > John Taylor <jd...@ro...> > Date: > Fri, 17 Nov 2006 15:03:53 +0000 > To: > Roy Williams <ro...@ca...> > > To: > Roy Williams <ro...@ca...> > CC: > Ray Plante <rp...@po...>, > pla...@so..., reg...@iv... > > > Hi Roy, > > Roy Williams wrote: > >> John >> >> Following your logic, this means that VOEvents can also be registered >> individually, rather than registering the server that handles them, >> as Ray suggests. I understand that LSST will be putting out thousands >> of event notices every night. Do you think the VO registry system >> will be able to handle the load? > As I say, there's not very many messages - we're not proposing that > whenever an app sends a message it gets registered. We're registering > the message "class" rather than "instance". I don't really know > enough about VOEvent to comment. >> >> Another problem is inflexibility. Suppose a group wishes to >> experiment with their own dialect of messages, and they want to >> change rapidly, adding and deleting. In the official (Ray) scheme, >> they would have a standalone message registry that may or may not be >> registered with the VO registry. In your scheme, each message is >> added and deleted from the entire global VO registry. > I think it's very flexible. While you're experimenting, don't > register the message. We're not registering them at the moment and > getting along just fine...it's just they wouldn't show up in any tools > that looked in the registry for them, which is probably what you'd > want anyway. Indeed, you could even choose a non-ivoid URI if you > wished. >> >> Of course it is much more convenient to have "everything in the >> registry", it is a one-stop shop instead of a two-stage process. But >> perhaps not always the best solution....... > Indeed. It might turn out that we don't register them after all, but > if so, no harm done. > > John >> >> Roy >> >> >> >> John Taylor wrote >>> a search of the registry reveals the ivo://..../loadVOTable message >>> >>> Ray Plante wrote: >>>> Instead, I would recommend the approach that is to be used by the >>>> VOSpace standard in which names are identified using a # suffix; e.g., >>>> >>>> ivo://votech.org/plastic#info/getIVORN >>> >> > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: John T. <jd...@ro...> - 2006-11-17 14:23:43
|
Hi Ray, First up, apologies for the delay in replying to this. There is A Reason behind the choice of ivoids as messages. They're meant to be unique, so using a URI seems to be reasonable. Why a registry URI? Well, we think that there could be a benefit in registering the messages as separate resources. Messages are unique and there aren't that many of them, so why not register them? That way the URI can be dereferenced to provide a (hopefully) unambiguous definition of what the message means, and who is responsible for its definition. It also opens up other possibilities: the user wants to find an application that can accept a VOTable, a search of the registry reveals the ivo://..../loadVOTable message VOResource, a follow up search then locates the applications that understand the message (assuming we've got as far as registering desktop applications). All this would be hidden away behind some clever helper app of course. Another possibility is you could have some Plastic message sender tool that could interrogate the registry to construct the GUI for any message. Now if we decide not to the register the messages, it doesn't impact on the registry at all...the messages are just rather odd opaque strings....so where's the harm? I do plan to register Plastic as a standard as you suggest - and will probably be bugging you on how to do this. BTW - we can't use URI fragments as you propose, since they have another meaning in Plastic. John PS - the choice of votech.org as an authority Id was a mistake (well, let's be fair - it was my mistake)...I shouldn't have polluted the votech.org authId. Ray Plante wrote: > Hi John et al. > > I don't know if this has been pointed out to you or not; however, the > Plastic Specification is using IVOA identifiers in a non-standard way > to identify its messages. > > The IVOA Identifiers specification > (http://www.ivoa.net/Documents/latest/IDs.html) states that the use of > the ivo indicates that the identifier has been registered with an IVOA > registry (section 3.2.2). > > To be compliant, each of the Plastic message identifiers would have to > be registered as a separate resource. While in principle this is > possible, this is highly discouraged. Instead, I would recommend the > approach that is to be used by the VOSpace standard in which names are > identified using a # suffix; e.g., > > ivo://votech.org/plastic#info/getIVORN > > For use of an identifier of this form to be compliant, only the > ivo://votech.org/plastic resource need be registered. We have a new > schema we are putting forward for this purpose called VOStandard > (http://www.ivoa.net/internal/IVOA/RegUpgradeSummer2006/VOStandard-v0.1.xsd). > > It defines two new Resource sub-classes, Standard and StandardService, > that registers the existance of a standard; the former is probably > most appropriate for Plastic. These types do not currently provide > metadata for defining what I might call properties (e.g. > info/getIVORN); however, we should probably add that. Note that the > standard being described need not be an IVOA standard. > > Please let me know if you have any comment or suggestions on this front. > The Registry WG is the WG that handles the Identifier standard. > > cheers, > Ray > > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: John T. <jd...@ro...> - 2006-11-17 10:09:43
|
Oh yes of course - you're quite right. Thomas Boch wrote: > John Taylor wrote: > >> Hi Thomas - just to clarify....at the moment if you did receive the >> argument, you'd ignore it, rather than have an error? >> John >> > > Sorry, I was unclear. > I meant that having an id for a votable is very important because this > id can then be used to identify a given table when using the > "showobjects" message. At the time, we (PLASTICers) have not defined a > message taking an image id as an argument. That was my point. > > If an application sends to current version of Aladin an > "ivo://votech.org/fits/image/loadFromURL" message with an extra > argument, it would just ignore it. > > Thomas > > >> Thomas Boch wrote: >> >>> Hi John, >>> >>> As we don't have yet a message taking an image id as an argument, it may >>> seem less critical than having an id for the "load votable" message. >>> I nevertheless support this proposition, for consistency and future >>> flexibility. >>> Cheers, >>> >>> Thomas >>> >>> John Taylor wrote: >>> >>> >>>> Hi All, >>>> I'd like to propose that the above message take an optional string id >>>> argument, for the same reasons that we allow one for VOTables >>>> (applications might change the URL as they pass the file around, but >>>> they should not change the id). If absent, the id will default to the >>>> URL. As for VOTables, this id argument should be optional for backwards >>>> compatibility, but strongly recommended in new apps. >>>> >>>> John. >>>> >>>> >>> >> -- >> ------------------------------------------------------------------------ >> AstroGrid/VOTech >> & >> WFAU, Institute for Astronomy, Edinburgh >> Skype:johndavidtaylor <skype:johndavidtaylor?chat> >> >> ------------------------------------------------------------------------ >> *Gratuitous advertising:* >> Plastic - http://plastic.sourceforge.net | AstroRuntime - >> http://www2.astrogrid.org/desktop >> AstroGrid - http://www.astrogrid.org | WFAU - >> http://www.roe.ac.uk/ifa/wfau/ >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Plastic-devs mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/plastic-devs >> > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: Thomas B. <bo...@ne...> - 2006-11-17 09:50:58
|
John Taylor wrote: > > Hi Thomas - just to clarify....at the moment if you did receive the > argument, you'd ignore it, rather than have an error? > John Sorry, I was unclear. I meant that having an id for a votable is very important because this id can then be used to identify a given table when using the "showobjects" message. At the time, we (PLASTICers) have not defined a message taking an image id as an argument. That was my point. If an application sends to current version of Aladin an "ivo://votech.org/fits/image/loadFromURL" message with an extra argument, it would just ignore it. Thomas > > Thomas Boch wrote: > > Hi John, > > > > As we don't have yet a message taking an image id as an argument, it may > > seem less critical than having an id for the "load votable" message. > > I nevertheless support this proposition, for consistency and future > > flexibility. > > Cheers, > > > > Thomas > > > > John Taylor wrote: > > > >> Hi All, > >> I'd like to propose that the above message take an optional string id > >> argument, for the same reasons that we allow one for VOTables > >> (applications might change the URL as they pass the file around, but > >> they should not change the id). If absent, the id will default to the > >> URL. As for VOTables, this id argument should be optional for backwards > >> compatibility, but strongly recommended in new apps. > >> > >> John. > >> > > > > > > -- > ------------------------------------------------------------------------ > AstroGrid/VOTech > & > WFAU, Institute for Astronomy, Edinburgh > Skype:johndavidtaylor <skype:johndavidtaylor?chat> > > ------------------------------------------------------------------------ > *Gratuitous advertising:* > Plastic - http://plastic.sourceforge.net | AstroRuntime - > http://www2.astrogrid.org/desktop > AstroGrid - http://www.astrogrid.org | WFAU - > http://www.roe.ac.uk/ifa/wfau/ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs |
|
From: Mark T. <m.b...@br...> - 2006-11-17 09:42:27
|
On Thu, 16 Nov 2006, John Taylor wrote: > Hi All, > I'd like to propose that the above message take an optional string id > argument, for the same reasons that we allow one for VOTables > (applications might change the URL as they pass the file around, but > they should not change the id). If absent, the id will default to the > URL. As for VOTables, this id argument should be optional for backwards > compatibility, but strongly recommended in new apps. agree. -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: John T. <jd...@ro...> - 2006-11-17 09:23:03
|
Hi Thomas - just to clarify....at the moment if you did receive the argument, you'd ignore it, rather than have an error? John Thomas Boch wrote: > Hi John, > > As we don't have yet a message taking an image id as an argument, it may > seem less critical than having an id for the "load votable" message. > I nevertheless support this proposition, for consistency and future > flexibility. > Cheers, > > Thomas > > John Taylor wrote: > >> Hi All, >> I'd like to propose that the above message take an optional string id >> argument, for the same reasons that we allow one for VOTables >> (applications might change the URL as they pass the file around, but >> they should not change the id). If absent, the id will default to the >> URL. As for VOTables, this id argument should be optional for backwards >> compatibility, but strongly recommended in new apps. >> >> John. >> > > -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: Thomas B. <bo...@ne...> - 2006-11-17 08:16:05
|
Hi John, As we don't have yet a message taking an image id as an argument, it may seem less critical than having an id for the "load votable" message. I nevertheless support this proposition, for consistency and future flexibility. Cheers, Thomas John Taylor wrote: > > Hi All, > I'd like to propose that the above message take an optional string id > argument, for the same reasons that we allow one for VOTables > (applications might change the URL as they pass the file around, but > they should not change the id). If absent, the id will default to the > URL. As for VOTables, this id argument should be optional for backwards > compatibility, but strongly recommended in new apps. > > John. |
|
From: John T. <jd...@ro...> - 2006-11-16 22:42:00
|
Hi All, I'd like to propose that the above message take an optional string id argument, for the same reasons that we allow one for VOTables (applications might change the URL as they pass the file around, but they should not change the id). If absent, the id will default to the URL. As for VOTables, this id argument should be optional for backwards compatibility, but strongly recommended in new apps. John. -- ------------------------------------------------------------------------ AstroGrid/VOTech & WFAU, Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ *Gratuitous advertising:* Plastic - http://plastic.sourceforge.net | AstroRuntime - http://www2.astrogrid.org/desktop AstroGrid - http://www.astrogrid.org | WFAU - http://www.roe.ac.uk/ifa/wfau/ |
|
From: Alasdair A. <aa...@as...> - 2006-11-10 13:50:01
|
John Taylor wrote: > My vote is for PLASTIC... I'll use that then! Al. |
|
From: John T. <jon...@gm...> - 2006-11-10 12:20:56
|
In my usual inconsistent way, I've used PLASTIC throughout the paper, but plastic as the keyword. Hmmm...as much as I dislike the general shoutiness of PLASTIC, the problem with mere "plastic" is that it's a common English word. My vote is for PLASTIC, but as usual I'm prepared to be shouted down if I'm completely wrong. Alasdair Allan wrote: > I'm going to add a Plastic keyword into my ADASS paper. Just so we're > synced up and everyone is using the same keyword, are people using, > > Plastic > > or > > PLASTIC > > we don't want half the papers under one, and the other half under the > other...? > > Al. > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs > > |
|
From: Noel W. <Noe...@ma...> - 2006-11-10 12:19:00
|
I'm using PLASTIC cheers noel. On 10 Nov 2006, at 12:15, Alasdair Allan wrote: > I'm going to add a Plastic keyword into my ADASS paper. Just so we're > synced up and everyone is using the same keyword, are people using, > > Plastic > > or > > PLASTIC > > we don't want half the papers under one, and the other half under the > other...? > > Al. > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs |
|
From: Alasdair A. <aa...@as...> - 2006-11-10 12:15:29
|
I'm going to add a Plastic keyword into my ADASS paper. Just so we're synced up and everyone is using the same keyword, are people using, Plastic or PLASTIC we don't want half the papers under one, and the other half under the other...? Al. |
|
From: Noel W. <Noe...@ma...> - 2006-11-09 14:01:31
|
Hi, I'd like to announce 2 new mailing lists for Astro Runtime (An API for the Virtual Observatory - http://www2.astrogrid.org/desktop/ astro-runtime ) * Astro Runtime Users - for people using the Astro Runtime in their own science, scripts or applications. http://lists.astrogrid.org/mailman/listinfo/astro-runtime-users * Astro Runtime Developers - for people developing the Astro Runtime. http://lists.astrogrid.org/mailman/listinfo/astro-runtime-devs Mailing list info is summarized at http://www2.astrogrid.org/desktop/astro-runtime/mailing-lists Many Thanks Noel Winstanley --- http://wiki.astrogrid.org/bin/view/Main/NoelWinstanley Senior Developer, AstroGrid Project. Jodrell Bank Observatory, University of Manchester Workbench - http://www.astrogrid.org/desktop | Astro Runtime - http://www.astrogrid.org/desktop/astro-runtime |
|
From: Alasdair A. <aa...@as...> - 2006-10-18 00:07:44
|
All, Alasdair Allan wrote: > Expect updates shortly... I'd like to announce a major update to my Plastic Monitor Dashboard Widget for Mac OS X Tiger (see attached screen shot). The new V2 of the widget can be downloaded from; http://www.estar.org.uk/software/plastic_monitor_widget.zip and this release should fix all of the display problems associated with the pre-alpha. Cheers, Al. |
|
From: Alasdair A. <aa...@as...> - 2006-10-14 08:07:39
|
John Taylor wrote: > There's also the issue of reading the .plastic file.... From a web page rather than a widget? I'd guess you can work around that by asking the user to do a POST, it doesn't need to upset the web application interface too much (AJAX means we no longer have to reload pages). It's still a pain though. You could also farm it out to a Flash applet which doesn't have the same sort of limitations (it has a whole different set), but my Flash is fairly weak. Al. |
|
From: John T. <jon...@gm...> - 2006-10-14 07:14:21
|
There's also the issue of reading the .plastic file.... Alasdair Allan wrote: > > John Taylor wrote: >> Looks very very cool. Look forward to seeing the live >> version....also...this 'ere javascript xml-rpc malarky then....is it >> generalisable to ordinary web pages or do we hit security problems >> again? > > We run into security problems, dashboard widgets are exempt from a lot > of the security restrains which normal javascript suffers. However you > can work around this one by using a back end proxy to forward the > request. I've got some PHP lying around which will do this... > > Al. > |
|
From: Alasdair A. <aa...@as...> - 2006-10-13 23:46:17
|
John Taylor wrote: > Looks very very cool. Look forward to seeing the live > version....also...this 'ere javascript xml-rpc malarky then....is > it generalisable to ordinary web pages or do we hit security > problems again? We run into security problems, dashboard widgets are exempt from a lot of the security restrains which normal javascript suffers. However you can work around this one by using a back end proxy to forward the request. I've got some PHP lying around which will do this... Al. |
|
From: John T. <jon...@gm...> - 2006-10-13 22:46:14
|
Looks very very cool. Look forward to seeing the live version....also...this 'ere javascript xml-rpc malarky then....is it generalisable to ordinary web pages or do we hit security problems again? Alasdair Allan wrote: > All, > > John Taylor wrote: >> You might have noticed that the "view plastic applications" page has >> been removed... for plastic developers it was quite handy to be able >> to see info on which apps were connected to the Hub, and what >> messages they claimed to support. > > Inspired by John's PAM, and because I wanted to figure out how to do > XML-RPC from Javascript, "Bored in Airport" productions gives you... > > The Plastic Monitor Dashboard Widget for Mac OS X Tiger > http://www.estar.org.uk/software/plastic_monitor_widget.zip > >> The application connects to your Plastic Hub... and reports on what >> other applications it finds. Not exactly a major advance in >> scientific computing, but quite handy. > > Ditto. > > Caveats! > > This is a buggy "release early" alpha, and has a bit too much absolute > rather than relative positioning in the CSS. Worse yet it also uses > the HTTP GET interface of the AG Hub for the initial poll of > registered applications. However it does do everything else via > asynchronous XML RPC, and I will be ripping the last vestiges of HTTP > out of the widget during ADASS if I get time (it's no longer > necessary, as I've now figured out how to do XML RPC from Javascript, > the point of the exercise!). > > Expect updates shortly, I'll drop a page onto the eSTAR website linked > from my PLASTIC page at > > http://www.estar.org.uk/wiki/index.php/Plastic > > in the very near future (next time I'm bored in an airport, which > should be within a day or so)... > > For the non-blessed amoungst you, that haven't got OSX boxes, see the > attached screenshots if you're interested. > > Cheers, > Al. > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ------------------------------------------------------------------------ > > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs > |
|
From: Alasdair A. <aa...@as...> - 2006-10-13 12:50:07
|
All, John Taylor wrote: > You might have noticed that the "view plastic applications" page > has been removed... for plastic developers it was quite handy to be > able to see info on which apps were connected to the Hub, and what > messages they claimed to support. Inspired by John's PAM, and because I wanted to figure out how to do XML-RPC from Javascript, "Bored in Airport" productions gives you... The Plastic Monitor Dashboard Widget for Mac OS X Tiger http://www.estar.org.uk/software/plastic_monitor_widget.zip > The application connects to your Plastic Hub... and reports on what > other applications it finds. Not exactly a major advance in > scientific computing, but quite handy. Ditto. Caveats! This is a buggy "release early" alpha, and has a bit too much absolute rather than relative positioning in the CSS. Worse yet it also uses the HTTP GET interface of the AG Hub for the initial poll of registered applications. However it does do everything else via asynchronous XML RPC, and I will be ripping the last vestiges of HTTP out of the widget during ADASS if I get time (it's no longer necessary, as I've now figured out how to do XML RPC from Javascript, the point of the exercise!). Expect updates shortly, I'll drop a page onto the eSTAR website linked from my PLASTIC page at http://www.estar.org.uk/wiki/index.php/Plastic in the very near future (next time I'm bored in an airport, which should be within a day or so)... For the non-blessed amoungst you, that haven't got OSX boxes, see the attached screenshots if you're interested. Cheers, Al. |
|
From: John T. <jd...@ro...> - 2006-10-11 08:11:45
|
You might have noticed that the "view plastic applications" page has been removed from the latest versions of the Workbench/AstroRuntime. This is because a) the implementation was a rush-job, and pretty poor b) it was felt that the information wasn't very useful to your user-in-the-street. Nevertheless, for plastic developers it was quite handy to be able to see info on which apps were connected to the Hub, and what messages they claimed to support. So.... Bored In An Airport Productions is pleased to announce PAM - the Plastic Application Monitor You can webstart it from http://plastic.sourceforge.net/tupperware/plastic-application-monitor/pam.jnlp and further information will be available from http://plastic.sourceforge.net/tupperware/plastic-application-monitor/ The application connects to your Plastic Hub (e.g. startable from http://www2.astrogrid.org/desktop), and reports on what other applications it finds. Not exactly a major advance in scientific computing, but quite handy. John -- ------------------------------------------------------------------------ AstroGrid/VOTech & Institute for Astronomy, Edinburgh Skype:johndavidtaylor <skype:johndavidtaylor?chat> ------------------------------------------------------------------------ |
29 messages has been excluded from this view by a project administrator.
