plastic-devs — Plastic Developers

[Plastic-devs] Applications Messaging - Questions for the community

[John T. <jon...@gm...>]

To kick off the discussion on applications messaging, Mike and I have  
posed a series of questions for the apps working group.  We have our  
own opinions on many of them, but want to hear the views of the  
community.
You might feel that the answers to some of the questions are obvious:  
that's fine, it's still good for us to get them clear at this early  
stage and we can move on.  Don't feel obliged to answer every  
question, but if you have strong views on something, let's hear them  
and get them down on the wiki.  If you have any questions that we  
should have asked, please do append them.

We'll then try to distill the collective wisdom of the community into  
a plan on how to proceed, given the time constraints.  I'm  
particularly interested in hearing what we think is doable in the  
time we have.  I hope that we can separate out some easy wins that we  
can implement quickly, while discussion of the harder stuff might  
take longer.



http://www.ivoa.net/twiki/bin/view/IVOA/ApplicationsMessaging

http://www.ivoa.net/twiki/bin/view/IVOA/ 
ApplicationsMessagingInitialQuestions


John

Re: [Plastic-devs] [Fwd: Applications Messaging Standard]

[Pedro O. <Ped...@sc...>]

Dear all,


I think it might be wise to propose something like the following to the
IVOA:

- that the IVOA endorses the PLASTIC as it is (the name is just a detail
for me, the important thing would be the concept) through an IVOA doc
that describes the current PLASTIC spec.

- the IVOA "evolves" the aforementioned standard to become become
whichever future applications messaging protocol we all agree with.

This would allow currently working Plastic-interacting applications to
keep in sync and doing their job, and would stop a possible delay in the
publication of something which is nearly finished by now (and I agree
that the Applications Messaging Protocol would probably need many
discussions on things which are not in PLASTIC or that should be
changed, etc.).

There is a precedent on this, I believe: if you remember, at the last
Moscow meeting, the proposal was done to "bless" the Cone Search non-
standard document to become a standard one with a number, and leave it
there for reference (as there were many services implementing it). I
think it was generally agreed that this was a good idea (sort of
"legacy" standard) althuogh I am not 100% sure of what the final
decision was in this respect.

This is a general IVOA issue, I would say: how to cope with already-
existing de-facto standards when they are taken over by the IVOA. 

In any case, I think the PLASTIC is now at a stage where it might be
worth to try and pursue this. Then we'll fulfil several needs from
several sides.

Cheers,
P.



On Tue, 2007-01-30 at 11:15 +0000, John Taylor wrote:
> Dear All,
> The IVOA exec has decided to consider the issue of application messaging 
> in the new Applications Working Group.  This is a very early stage, 
> nothing is ruled in or out, and whether the outcome of the WG will 
> include an endorsement of PLASTIC, something derived from PLASTIC, or 
> something completely different is unknown.  If you have strong opinions 
> on what you need to have from an IVOA-endorsed apps messaging standard 
> then please keep a close eye on the ap...@iv... list.  In the 
> meantime, until things are clearer, feel free to continue to use this 
> list for questions and discussion related to PLASTIC.
> 
> John
> 
> PS
> Apologies for the multiple posting - I'm sure most of you received 
> Mark's original post.
> 
> -------- Original Message --------
> Subject: 	Applications Messaging Standard
> Date: 	Tue, 30 Jan 2007 11:31:48 +0100
> From: 	Mark Allen <al...@ne...>
> Reply-To: 	Mark Allen <al...@ne...>
> To: 	ap...@iv...
> 
> 
> 
> Dear Apps WG,
> 
> One of the first tasks of the Applications working group is to
> consider how an applications messaging standard may be developed as
> an IVOA standard. Plastic (see IVOA Note: PLASTIC - a protocol for
> desktop application interoperability Version 1.00) is a successful
> protocol which has been adopted by a several VO Applications and there
> is much interest in having a IVOA standard for semantics and syntax of
> application messaging.
> 
> John Taylor (Royal Obs Edinburgh) and Mike Fitzpatrick (NOAO) have
> agreed to lead an initial discussion on this mailing list about messaging
> between VO applications in general.
> 
> A proposed work-plan and time line are set out below. This is of course
> a draft, and is quite ambitious. I would however issue the challenge
> to have some well developed examples and demos by the May Interop
> meeting in Beijing.
> 
> -Mark.
> 
> -------------------------------------------------------------------
> 
> Draft Work-plan and Time-line.
> 
> 1. Investigate the scope of an Applications messaging IVOA standard.
> 
> 1.1 Open mailing list discussion on messaging between VO apps in general.
> - capture major concepts
> - identify interested parties
> (Feb 2007)
> 
> 1.2 Prepare a short note on "Applications messaging for VO tools"
> - define the scope of an Applications Messaging IVOA standard
> - outline the major issues involved, and put the current possibilities
> into the context of short and longer term goals.
> (end-Feb 2007)
> 
> 1.3 Draft mission plan for standard development
> (Mar 2007)
> 
> 2. IVOA Apps Applications Messaging Team
> 
> - small team (~10) defined by WG Chair and team leads. (Mar 2007)
> - finalise mission plan
> - develop the standard and to prepare an IVOA Working Draft.
> 
> 
> 3. First working draft by team (April ?)
> 
> 
> 4. May Interoperability Meeting (Beijing)
> - Working draft to mailing list before meeting
> - present status of Applications Messaging to IVOA community
> - Awe inspiring demo/examples
> 
> 5. Working Draft -> Proposed Recommendation
> 
> 
> 
> 
> 
> -- 
> Mark G. ALLEN
> Observatoire de Strasbourg
> +33 3 90 24 24 87
> 
> 
> 
-- 
Pedro Osuna Alcalaya

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Research and Scientific Support Department (RSSD)
Astronomy Science Operations Division (SCI-SD)
e-mail: Ped...@es...
Tel + 34 91 813 13 14    Fax: +34 91 813 11 72
-------------------------------------------------                                                                                
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN

================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================

[Plastic-devs] [Fwd: Applications Messaging Standard]

[John T. <jd...@ro...>]

Dear All,
The IVOA exec has decided to consider the issue of application messaging 
in the new Applications Working Group.  This is a very early stage, 
nothing is ruled in or out, and whether the outcome of the WG will 
include an endorsement of PLASTIC, something derived from PLASTIC, or 
something completely different is unknown.  If you have strong opinions 
on what you need to have from an IVOA-endorsed apps messaging standard 
then please keep a close eye on the ap...@iv... list.  In the 
meantime, until things are clearer, feel free to continue to use this 
list for questions and discussion related to PLASTIC.

John

PS
Apologies for the multiple posting - I'm sure most of you received 
Mark's original post.

-------- Original Message --------
Subject: 	Applications Messaging Standard
Date: 	Tue, 30 Jan 2007 11:31:48 +0100
From: 	Mark Allen <al...@ne...>
Reply-To: 	Mark Allen <al...@ne...>
To: 	ap...@iv...



Dear Apps WG,

One of the first tasks of the Applications working group is to
consider how an applications messaging standard may be developed as
an IVOA standard. Plastic (see IVOA Note: PLASTIC - a protocol for
desktop application interoperability Version 1.00) is a successful
protocol which has been adopted by a several VO Applications and there
is much interest in having a IVOA standard for semantics and syntax of
application messaging.

John Taylor (Royal Obs Edinburgh) and Mike Fitzpatrick (NOAO) have
agreed to lead an initial discussion on this mailing list about messaging
between VO applications in general.

A proposed work-plan and time line are set out below. This is of course
a draft, and is quite ambitious. I would however issue the challenge
to have some well developed examples and demos by the May Interop
meeting in Beijing.

-Mark.

-------------------------------------------------------------------

Draft Work-plan and Time-line.

1. Investigate the scope of an Applications messaging IVOA standard.

1.1 Open mailing list discussion on messaging between VO apps in general.
- capture major concepts
- identify interested parties
(Feb 2007)

1.2 Prepare a short note on "Applications messaging for VO tools"
- define the scope of an Applications Messaging IVOA standard
- outline the major issues involved, and put the current possibilities
into the context of short and longer term goals.
(end-Feb 2007)

1.3 Draft mission plan for standard development
(Mar 2007)

2. IVOA Apps Applications Messaging Team

- small team (~10) defined by WG Chair and team leads. (Mar 2007)
- finalise mission plan
- develop the standard and to prepare an IVOA Working Draft.


3. First working draft by team (April ?)


4. May Interoperability Meeting (Beijing)
- Working draft to mailing list before meeting
- present status of Applications Messaging to IVOA community
- Awe inspiring demo/examples

5. Working Draft -> Proposed Recommendation





-- 
Mark G. ALLEN
Observatoire de Strasbourg
+33 3 90 24 24 87



-- 
------------------------------------------------------------------------
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/

Re: [Plastic-devs] Plastic and monitoring

[John T. <jd...@ro...>]

Hi Paul,
Thanks for your post, and apologies for the late reply. 
This looks interesting.   Norman has already pointed me at MonAMI and 
I'm interested in looking at it as a means for monitoring our services 
(even without the possible PLASTIC link-up).  Currently I'm using the 
MARS network monitor for this purpose (see http://vomon.sourceforge.net) 
but I'm keen to  explore alternatives, especially if they come from 
other grid projects.  [In fact, it's possible I will even have an MSc 
student to work on this area].  Maybe we should have a chat offlist 
about how we could get MonAMI to monitor our services at Edinburgh?

As for pushing out status reports via PLASTIC, currently plastic 
messaging is local to a user's machine.  Do you typically deploy MonAMI 
on a user's desktop or is it more a server-side application?  I guess 
it's more the latter, so PLASTIC in its present form isn't very useful 
to you.  However, it would be good to discuss how we might extend it to 
allow messaging between machines.

John

Paul Millar wrote:
> Hi all,
>
> By way of introduction, I'm currently looking at monitoring.  In particular, 
> at developing a "universal" sensor for grid applications.  This is primarily 
> within High-energy grid community but I hope this has uses further afield.
>
> The focus is in developing code to support plugin-based monitoring: both in 
> terms of what is monitored and where the information is sent.  The result is 
> the MonAMI project:
>   http://monami.sourceforge.net/
>
> The idea behind MonAMI is that services (such as new grid services) that are 
> to be monitored provide this functionality as a plug-in for MonAMI.  MonAMI 
> can be configured to route this information to wherever its needed using 
> whatever plugins exist and have been configured (e.g. ganglia, nagios, ...).  
> This allows local site-administrators to integrate grid-service monitoring 
> within their existing fabric monitoring.
>
> A college (working for the VOTech project) mentioned plastic as a means for 
> inter-communications.  Looking at the aims for plastic, I think it might be 
> of use as a transport for monitoring information.  Implement a plastic 
> plug-in for MonAMI looks to be fairly straight-forward.  Such a plug-in would 
> allow MonAMI to send data to the hub for relaying to whoever is registered 
> with the hub.  This would happen independently of other monitoring activity 
> (such as updating ganglia graphs).
>
> MonAMI intrinsically supports periodic pushing of data, on-demand monitoring 
> (in this case, triggered by other plastic clients) and event-based 
> asynchronous monitoring.  With a suitable set of plastic monitoring messages, 
> it should be possible to support all these monitoring flows, although perhaps 
> not all are necessary here.
>
> I don't know if others are looking at providing monitoring via plastic, or if 
> other mechanisms exist, but this might be worth looking into.
>
> Cheers,
>
> Paul.
>   


-- 
------------------------------------------------------------------------
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/

[Plastic-devs] Plastic and monitoring

[Paul M. <p.m...@ph...>]

[resending as mailto:pla...@so... didn't work]

----------  Forwarded Message  ----------
Hi all,

By way of introduction, I'm currently looking at monitoring.  In particular,
at developing a "universal" sensor for grid applications.  This is primarily
within High-energy grid community but I hope this has uses further afield.

The focus is in developing code to support plugin-based monitoring: both in
terms of what is monitored and where the information is sent.  The result is
the MonAMI project:
  http://monami.sourceforge.net/

The idea behind MonAMI is that services (such as new grid services) that are
to be monitored provide this functionality as a plug-in for MonAMI.  MonAMI
can be configured to route this information to wherever its needed using
whatever plugins exist and have been configured (e.g. ganglia, nagios, ...).
This allows local site-administrators to integrate grid-service monitoring
within their existing fabric monitoring.

A college (working for the VOTech project) mentioned plastic as a means for
inter-communications.  Looking at the aims for plastic, I think it might be
of use as a transport for monitoring information.  Implement a plastic
plug-in for MonAMI looks to be fairly straight-forward.  Such a plug-in would
allow MonAMI to send data to the hub for relaying to whoever is registered
with the hub.  This would happen independently of other monitoring activity
(such as updating ganglia graphs).

MonAMI intrinsically supports periodic pushing of data, on-demand monitoring
(in this case, triggered by other plastic clients) and event-based
asynchronous monitoring.  With a suitable set of plastic monitoring messages,
it should be possible to support all these monitoring flows, although perhaps
not all are necessary here.

I don't know if others are looking at providing monitoring via plastic, or if
other mechanisms exist, but this might be worth looking into.

Cheers,

Paul.

[Plastic-devs] SPAM problems

[John T. <jd...@ro...>]

Apologies for the recent spam on the list.  I've temporarily enabled 
posting moderation until I can ascertain how serious the problem is 
going to be and whether we can do anything about it.  This will result 
in your posts being delayed a little.

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/

Re: [Plastic-devs] Announce: Plastic Note Published

[John T. <jd...@ro...>]

I'm going to republish the website tomorrow, removing the out of date 
documentation and linking to the new IVOA Note.  If you have anything 
you'd like me to add (e.g. to the FAQ 
http://plastic.sourceforge.net/faq.html ) at the same time then let me know.

John

John Taylor wrote:
> Hi All,
> I'm pleased to announce that the first IVOA Note describing the 
> Plastic Protocol has now been published.  It includes a few minor 
> changes from the version I sent round for comments last week.  If you 
> have any comments or corrections please do let me know, and I'll see 
> if I can work them into the next version.
>
> http://ivoa.net/Documents/latest/PlasticDesktopInterop.html
>
>
> John
>
> PS
> You might be a little surprised by the date on the document.  This 
> small untruth is necessary as I needed to publish the document at a 
> placeholder URL that people have been using as a reference for some 
> time, and the IVOA's publishing rules require that the date on the 
> document match the URL.  It just goes to show how long this document 
> has been in prep...
>


-- 
------------------------------------------------------------------------
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/

[Plastic-devs] Announce: Plastic Note Published

[John T. <jd...@ro...>]

Hi All,
I'm pleased to announce that the first IVOA Note describing the Plastic 
Protocol has now been published.  It includes a few minor changes from 
the version I sent round for comments last week.  If you have any 
comments or corrections please do let me know, and I'll see if I can 
work them into the next version.

http://ivoa.net/Documents/latest/PlasticDesktopInterop.html


John

PS
You might be a little surprised by the date on the document.  This small 
untruth is necessary as I needed to publish the document at a 
placeholder URL that people have been using as a reference for some 
time, and the IVOA's publishing rules require that the date on the 
document match the URL.  It just goes to show how long this document has 
been in prep...

-- 
------------------------------------------------------------------------
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/

Re: [Plastic-devs] IVOA Note on PLASTIC

[Isa B. <Isa...@sc...>]

Dear John et al.
thanks for the excellent work made with this first Note of the Plastic 
implementation.
I just have a couple of suggestions/comments that I hope can be of some 
utility.

1) I would find useful to have listed in the section 2.1.1 all the 
existing defined messages, because I think they represent the final 
purpose of the applications developing Plastic and in my opinion they 
should be listed in the Protocol Specification.
They could be update with each new version of the document and they 
could give a general view of the progress made by the Plastic 
implementation.

2) Showing Screenshots and graphic examples can be very useful to 
illustrate what are the practical capabilities of the Plastic Messages 
and I think this is actually supporting the idea to have all the 
messages listed and described as above (point 1) as they can highlight 
the utility of Plastic from the purpose side.
I've also noticed that spectra are mentioned only in few examples. I'm 
about to release a new version of VOSpec implementing the "Interop Menu" 
and I hope for the next release of the Plastic Specification VOSpec 
could be displayed as example or reference for the spectra messages.

I hope this can be useful.
Cheers,
Isa


John Taylor wrote:
> Dear All (again).  Apologies for the broken link, the correct link is below:
>
> http://tinyurl.com/ymb3jg
>
> John
>
> John Taylor wrote:
>   
>> Dear All,
>> Please find below a link to the draft PLASTIC IVOA note that Thomas, 
>> Marco, Mark, Noel and I have prepared.
>>
>>
>>
>> Although this is only a Note and so doesn't need to go through any 
>> formal review process, we thought it fair to give you the chance to 
>> comment on it before publication, if you wish.
>> I intend to publish the Note in a week's time, provided too many 
>> changes aren't required.
>>
>> Regards,
>> John
>>
>>
>>
>>
>>
>>     
>
>
>   

================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================

Re: [Plastic-devs] Occasionally asked questions

[Marco C. <mar...@oa...>]

John Taylor wrote:
> Hi All,
> PLASTIC has been getting a higher profile of late, especially since 
> ADASS, and I've noticed a few misconceptions about what it is and what 
> it does.   The two most common are that
> a) PLASTIC is an AstroGrid product.  I find this one particularly 
> annoying as it doesn't recognise the contributions made by Thomas and 
> Marco in particular, but I'm to blame as I've used PLASTIC to pay my 
> airfare to the last few meetings.  Ironically, I don't even work for 
> AstroGrid. (well, they don't pay me, anyway)
> b) PLASTIC is Java-only.  This is an understandable mix-up, given that 
> the majority of plasticized applications are indeed written in Java, but 
> this reflects the current technology choices of app developers, it's 
> nothing to do with PLASTIC.
> 
> Do you think there's anything to be gained in having a prominent FAQ on 
> Plastic Central that addresses these issues as we encounter them?

Hi John,

I was at the VObs.it workshop last week talking about PLASTIC. People
were very interested in it and I got a lot of questions. One of the most
frequent was something like this

Can PLASTIC startup an application?

Another one was more technical

How are web pages plasticized?


I hope that could help,
cheers,
Marco

Re: [Plastic-devs] IVOA Note on PLASTIC

[John T. <jd...@ro...>]

Dear All (again).  Apologies for the broken link, the correct link is below:

http://tinyurl.com/ymb3jg

John

John Taylor wrote:
> Dear All,
> Please find below a link to the draft PLASTIC IVOA note that Thomas, 
> Marco, Mark, Noel and I have prepared.
>
>
>
> Although this is only a Note and so doesn't need to go through any 
> formal review process, we thought it fair to give you the chance to 
> comment on it before publication, if you wish.
> I intend to publish the Note in a week's time, provided too many 
> changes aren't required.
>
> Regards,
> 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/

[Plastic-devs] IVOA Note on PLASTIC

[John T. <jd...@ro...>]

Dear All,
Please find below a link to the draft PLASTIC IVOA note that Thomas, 
Marco, Mark, Noel and I have prepared.

http://wiki.astrogrid.org/pub/Main/JohnTaylor/PlasticDesktopInteropProtocol6.pdf

Although this is only a Note and so doesn't need to go through any 
formal review process, we thought it fair to give you the chance to 
comment on it before publication, if you wish. 

I intend to publish the Note in a week's time, provided too many changes 
aren't required.

Regards,
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/

Re: [Plastic-devs] Occasionally asked questions

[John T. <jon...@gm...>]

Alasdair Allan wrote:
> Noel Winstanley wrote:
>   
>> I think this is a pretty good idea.
>>     
>
> Me too...
>
>   
>>> Is PLASTIC Java only?
>>>
>>>     No! PLASTIC is designed to be language and platform neutral.
>>> Applications that understand PLASTIC have been written in C++,
>>> Python, Perl, Tcl and Ruby.
>>>       
>> you could add to this that no matter what language they're
>> implemented in, they all work together. And that they've been
>> demonstrated in public (adass) doing so. You could give a concrete
>> example - visivo, Erik, topcat maybe. Isn't there even a flash movie
>> of this somewhere?
>>     
>
> There is Perl and Javascript code to talk to the Plastic Hub on the  
> eSTAR website. I could try and get it into a slightly more compressed  
> and oragnised fashion I suppose, but for now most of it is at; http:// 
> www.estar.org.uk/wiki/index.php/Plastic
>   
Thanks Alasdair.  At the moment I link to you from:
http://plastic.sourceforge.net/plastic_in.html

but I probably ought to get the code on the website in some easily 
digestible form.

>   
>> I think you need to mention the other main transport protocol -
>> XMLRPC - in the answer - and make it clear that RMI doesn't have any
>> kind of 'special status'. In fact,  some applications written in java
>> choose to use xmlrpc anyhow (topcat).
>>     
>
> I think mentioning XML-RPC prominently will convince people that it's  
> language neutral rather than Java specific.
>
>   
>> 'what's the relationship between PLASTIC and AstroRuntime' (copy from
>> http://www2.astrogrid.org/desktop/astro-runtime/astroruntime-and-
>> plastic if you find it agreeable).
>>     
>
> Might be a reasonable idea to offer a Plastic Hub (just the Plastic  
> Hub) on the SourceForge site (somewhere prominent, like the front  
> page) and have the links to the full WorkBench elsewhere.
>
> Having something like "Download a Plastic Hub HERE", rather than a  
> complicated discussion about the AR, Workbench and how it all relates  
> to Plastic, might be a more attractive option for new users...?
>   
Good point.  The new user is somewhat overwhelmed with choice at the moment.


> Al.
>
>
> -------------------------------------------------------------------------
> 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
>
>   

Re: [Plastic-devs] Occasionally asked questions

[Alasdair A. <aa...@as...>]

Mark Taylor wrote:
>  John Taylor wrote:
>> I've made a rough start (attached, without css)  - if anyone wants  
>> to add
>> something (or indeed, thinks it's a rubbish idea), then let me know.
>
> I find the "it's not Java-centric honest" rhetoric to be slightly
> disingenuous: what is true is that the hub has to be written in Java
> (um, unless you want to try to fake Java RMI-Lite communications from
> Python ... good luck).  I'm not sure whether you're avoiding emphasis
> of this fact in order to serve the greater good, or if it's an  
> oversight.

Greater good presumably...

I do have a partial hub implementation in Perl although it'd need a  
bunch of cleaning up if I was ever to release it, but of course it  
doesn't even try and do RMI (although that is theoretically possible  
and I sort of know how I'd start to fake it out, it'd take a long  
time and I can't be bothered really) just XMLRPC and (bits and pieces  
of REST).

Al.

Re: [Plastic-devs] Occasionally asked questions

[Alasdair A. <aa...@as...>]

Noel Winstanley wrote:
> I think this is a pretty good idea.

Me too...

>> Is PLASTIC Java only?
>>
>>     No! PLASTIC is designed to be language and platform neutral.
>> Applications that understand PLASTIC have been written in C++,
>> Python, Perl, Tcl and Ruby.
>
>
> you could add to this that no matter what language they're
> implemented in, they all work together. And that they've been
> demonstrated in public (adass) doing so. You could give a concrete
> example - visivo, Erik, topcat maybe. Isn't there even a flash movie
> of this somewhere?

There is Perl and Javascript code to talk to the Plastic Hub on the  
eSTAR website. I could try and get it into a slightly more compressed  
and oragnised fashion I suppose, but for now most of it is at; http:// 
www.estar.org.uk/wiki/index.php/Plastic

> I think you need to mention the other main transport protocol -
> XMLRPC - in the answer - and make it clear that RMI doesn't have any
> kind of 'special status'. In fact,  some applications written in java
> choose to use xmlrpc anyhow (topcat).

I think mentioning XML-RPC prominently will convince people that it's  
language neutral rather than Java specific.

> 'what's the relationship between PLASTIC and AstroRuntime' (copy from
> http://www2.astrogrid.org/desktop/astro-runtime/astroruntime-and-
> plastic if you find it agreeable).

Might be a reasonable idea to offer a Plastic Hub (just the Plastic  
Hub) on the SourceForge site (somewhere prominent, like the front  
page) and have the links to the full WorkBench elsewhere.

Having something like "Download a Plastic Hub HERE", rather than a  
complicated discussion about the AR, Workbench and how it all relates  
to Plastic, might be a more attractive option for new users...?

Al.

Re: [Plastic-devs] Occasionally asked questions

[Mark T. <m.b...@br...>]

On Thu, 23 Nov 2006, Noel Winstanley wrote:

>
> On 23 Nov 2006, at 14:33, Mark Taylor wrote:
>
>> On Thu, 23 Nov 2006, John Taylor wrote:
>> 
>>> Do you think there's anything to be gained in having a prominent FAQ on
>>> Plastic Central that addresses these issues as we encounter them?
>> 
>> good idea.
>> 
>>> I've made a rough start (attached, without css)  - if anyone wants to add
>>> something (or indeed, thinks it's a rubbish idea), then let me know.
>> 
>> I find the "it's not Java-centric honest" rhetoric to be slightly
>> disingenuous: what is true is that the hub has to be written in Java
>> (um, unless you want to try to fake Java RMI-Lite communications from
>> Python ... good luck).  I'm not sure whether you're avoiding emphasis
>> of this fact in order to serve the greater good, or if it's an oversight.
>> 
>
> does / should the plastic spec mandate that java-rmi must be supported in a 
> valid implementation of a hub?
> an xml-rpc hub could certainly be written in python.

that's certainly true - the only part of PLASTIC which requires Java
is support for the java RMI protocol in the hub.  If that protocol
were made optional, then a hub could be written in any language.

It's also true of course that this isn't a concern of application authors,
only hub authors - you should indeed emphasise that there's nothing 
java-like that people writing PLASTIC client applications has to do.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

Re: [Plastic-devs] Occasionally asked questions

[Mark T. <m.b...@br...>]

On Thu, 23 Nov 2006, Noel Winstanley wrote:

> kind of 'special status'. In fact,  some applications written in java
> choose to use xmlrpc anyhow (topcat).

<pedantic>
not quite true - TOPCAT does use XML-RPC to do MySpace access via
the AR, but not for PLASTIC communications.  There's no particularly
good reason for this.  My PLASTIC unit tests do exercise XML-RPC 
PLASTIC communications though.
</pedantic>

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

Re: [Plastic-devs] Occasionally asked questions

[Mark T. <m.b...@br...>]

On Thu, 23 Nov 2006, Noel Winstanley wrote:

>> I find the "it's not Java-centric honest" rhetoric to be slightly
>> disingenuous: what is true is that the hub has to be written in Java
>> (um, unless you want to try to fake Java RMI-Lite communications from
>> Python ... good luck).  I'm not sure whether you're avoiding emphasis
>> of this fact in order to serve the greater good, or if it's an oversight.
>> 
>
> does / should the plastic spec mandate that java-rmi must be supported in a 
> valid implementation of a hub?
> an xml-rpc hub could certainly be written in python.
>
> there's other transports / encodings that you could consider adding to such a 
> hub - JSON being the currently most fashionable - http:// 
> en.wikipedia.org/wiki/Json - because of it's utiility in ajax-like things.
>
> should a minimum set of transports be mandatatory for a hub? or, if not, is 
> there a way of describing what transports a hub supports (something in the 
> .plastic file maybe?)

I suppose this is not explicitly stated anywhere, but I always assumed
that a compliant hub was obliged to support all of (i.e. currently both) 
the defined transport protocols.  If it doesn't, then some applications
are going to find themselves locked out of PLASTIC conversations on 
some desktops.

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

Re: [Plastic-devs] Occasionally asked questions

[Noel W. <Noe...@ma...>]

On 23 Nov 2006, at 14:33, Mark Taylor wrote:

> On Thu, 23 Nov 2006, John Taylor wrote:
>
>> Do you think there's anything to be gained in having a prominent  
>> FAQ on
>> Plastic Central that addresses these issues as we encounter them?
>
> good idea.
>
>> I've made a rough start (attached, without css)  - if anyone wants  
>> to add
>> something (or indeed, thinks it's a rubbish idea), then let me know.
>
> I find the "it's not Java-centric honest" rhetoric to be slightly
> disingenuous: what is true is that the hub has to be written in Java
> (um, unless you want to try to fake Java RMI-Lite communications from
> Python ... good luck).  I'm not sure whether you're avoiding emphasis
> of this fact in order to serve the greater good, or if it's an  
> oversight.
>

does / should the plastic spec mandate that java-rmi must be  
supported in a valid implementation of a hub?
an xml-rpc hub could certainly be written in python.

there's other transports / encodings that you could consider adding  
to such a hub - JSON being the currently most fashionable - http:// 
en.wikipedia.org/wiki/Json - because of it's utiility in ajax-like  
things.

should a minimum set of transports be mandatatory for a hub? or, if  
not, is there a way of describing what transports a hub supports  
(something in the .plastic file maybe?)


> -- 
> Mark Taylor   Astronomical Programmer   Physics, Bristol  
> University, UK
> m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/ 
> ~mbt/
>
> ---------------------------------------------------------------------- 
> ---
> 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

Re: [Plastic-devs] Occasionally asked questions

[Mark T. <m.b...@br...>]

On Thu, 23 Nov 2006, John Taylor wrote:

> Do you think there's anything to be gained in having a prominent FAQ on 
> Plastic Central that addresses these issues as we encounter them?

good idea.

> I've made a rough start (attached, without css)  - if anyone wants to add 
> something (or indeed, thinks it's a rubbish idea), then let me know.

I find the "it's not Java-centric honest" rhetoric to be slightly 
disingenuous: what is true is that the hub has to be written in Java
(um, unless you want to try to fake Java RMI-Lite communications from
Python ... good luck).  I'm not sure whether you're avoiding emphasis 
of this fact in order to serve the greater good, or if it's an oversight.

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

Re: [Plastic-devs] Occasionally asked questions

[Noel W. <Noe...@ma...>]

I think this is a pretty good idea.

comments.
who?
   - describe a little more what VOTech is (Vo for Europe?) and as  
well as the main groups, mention Mark Taylor, and other individuals.

General

>  Is PLASTIC an AstroGrid product?
>
>     No! PLASTIC has been mainly developed by the VOTech consortium,  
> but others have contributed. AstroGrid's connection is that they  
> are a member of the consortium and have produced some "plasticized"  
> software such as the reference Plastic Hub.

it might be good to fill out this answer by listing all the work done  
by other organizations / individuals in and out of VOTech .

> s PLASTIC Java only?
>
>     No! PLASTIC is designed to be language and platform neutral.  
> Applications that understand PLASTIC have been written in C++,  
> Python, Perl, Tcl and Ruby.


you could add to this that no matter what language they're  
implemented in, they all work together. And that they've been  
demonstrated in public (adass) doing so. You could give a concrete  
example - visivo, Erik, topcat maybe. Isn't there even a flash movie  
of this somewhere?

>  Why does PLASTIC use Java-RMI then?
>
>     Java RMI is just one of the "transport protocols" available to  
> plasticized applications. It is there as a convenience to Java  
> programmers, recognising that many desktop applications are  
> currently being developed in Java.
>     [top]

I think you need to mention the other main transport protocol -  
XMLRPC - in the answer - and make it clear that RMI doesn't have any  
kind of 'special status'. In fact,  some applications written in java  
choose to use xmlrpc anyhow (topcat).

another thing to add to your faq - things that relates to the plastic  
manifesto and general philosophy of you plastic-devs chaps  - e.g.  
answers to 'why doesn't it encrypt messages', 'why doesn't it tunnel   
though firewalls',

Other questions to consider
'how can I download the source'
'can I use plastic to connect to servers',
'can I use plastic to control other people's desktop',
'why not use corba instead? / could plastic messages be sent over corba'
'why not use SOAP instead / could plastic messages be sent using SOAP?'
'why aren't the messages defined using XML schemas?'
' can I define new messages'
'what's the relationship between PLASTIC and AstroRuntime' (copy from
http://www2.astrogrid.org/desktop/astro-runtime/astroruntime-and- 
plastic if you find it agreeable).



Anyhow, looks good so far.

right - must get back to painting the house.
noel.


On 23 Nov 2006, at 12:48, John Taylor wrote:

> Hi All,
> PLASTIC has been getting a higher profile of late, especially since  
> ADASS, and I've noticed a few misconceptions about what it is and  
> what it does.   The two most common are that
> a) PLASTIC is an AstroGrid product.  I find this one particularly  
> annoying as it doesn't recognise the contributions made by Thomas  
> and Marco in particular, but I'm to blame as I've used PLASTIC to  
> pay my airfare to the last few meetings.  Ironically, I don't even  
> work for AstroGrid. (well, they don't pay me, anyway)
> b) PLASTIC is Java-only.  This is an understandable mix-up, given  
> that the majority of plasticized applications are indeed written in  
> Java, but this reflects the current technology choices of app  
> developers, it's nothing to do with PLASTIC.
>
> Do you think there's anything to be gained in having a prominent  
> FAQ on Plastic Central that addresses these issues as we encounter  
> them?
>
> I've made a rough start (attached, without css)  - if anyone wants  
> to add something (or indeed, thinks it's a rubbish idea), then let  
> me know.
>
> John
>
> PS
> Does anyone want/need write access to the website?  You only need  
> to ask....
>
>
> -- 
> ---------------------------------------------------------------------- 
> --
> 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/
> <faq.7110DEFANGED-html>
> ---------------------------------------------------------------------- 
> ---
> 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

[Plastic-devs] Occasionally asked questions

[John T. <jd...@ro...>]

Hi All,
PLASTIC has been getting a higher profile of late, especially since 
ADASS, and I've noticed a few misconceptions about what it is and what 
it does.   The two most common are that
a) PLASTIC is an AstroGrid product.  I find this one particularly 
annoying as it doesn't recognise the contributions made by Thomas and 
Marco in particular, but I'm to blame as I've used PLASTIC to pay my 
airfare to the last few meetings.  Ironically, I don't even work for 
AstroGrid. (well, they don't pay me, anyway)
b) PLASTIC is Java-only.  This is an understandable mix-up, given that 
the majority of plasticized applications are indeed written in Java, but 
this reflects the current technology choices of app developers, it's 
nothing to do with PLASTIC.

Do you think there's anything to be gained in having a prominent FAQ on 
Plastic Central that addresses these issues as we encounter them?

I've made a rough start (attached, without css)  - if anyone wants to 
add something (or indeed, thinks it's a rubbish idea), then let me know.

John

PS
Does anyone want/need write access to the website?  You only need to ask....


-- 
------------------------------------------------------------------------
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/

Re: [Plastic-devs] illegal/unrecommended use of IVOA identifiers

[John T. <jon...@gm...>]

Hi Ray -
This sounds promising (apart from Mark having spotted the gotcha in the 
URI spec).  It also could tie in quite neatly with  Doug's idea about 
namespacing the different "languages".
John

Ray Plante wrote:
> Hi,
>
> On Fri, 17 Nov 2006, John Taylor wrote:
>   
>> It's certainly an alternative worth considering, though I see two problems: 
>> 1) we're already using the #fragment for something else
>>     
>
> You can do what ever you like after the # following the IVOA id, including 
> having another pound.
>
> If it helps, ? has the exact same effect from the IVOA ID perspective--it 
> marks the end of the identifier that is resolvable via the registry.  You 
> could then have messages that look like
>
>     ivo://votech.org/plastic?info/getIVORN#...
>
> 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?
>>     
>
> So by avoiding centralization, I take you mean that you want to allow 
> anyone to define a new message.  My recommendation is that that through 
> one Standard resource record, one can define a set of properties (that are 
> presumably related).  You define your core Plastic message; Alasdair, in a 
> sepearate Standard record, defines his extended set.  Applications can 
> either describe support for whole sets or individual properties.
>
> I think it can work.
>
> cheers,
> 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
>
>   

Re: [Plastic-devs] illegal/unrecommended use of IVOA identifiers

[Mark T. <m.b...@br...>]

On Fri, 17 Nov 2006, Ray Plante wrote:

> On Fri, 17 Nov 2006, John Taylor wrote:
>> It's certainly an alternative worth considering, though I see two problems:
>> 1) we're already using the #fragment for something else
>
> You can do what ever you like after the # following the IVOA id, including
> having another pound.

By my reading of RFC2396 a string of this form would not be a legal URI.

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

Re: [Plastic-devs] illegal/unrecommended use of IVOA identifiers

[Ray P. <rp...@po...>]

Hi,

On Fri, 17 Nov 2006, John Taylor wrote:
> It's certainly an alternative worth considering, though I see two problems: 
> 1) we're already using the #fragment for something else

You can do what ever you like after the # following the IVOA id, including 
having another pound.

If it helps, ? has the exact same effect from the IVOA ID perspective--it 
marks the end of the identifier that is resolvable via the registry.  You 
could then have messages that look like

    ivo://votech.org/plastic?info/getIVORN#...

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?

So by avoiding centralization, I take you mean that you want to allow 
anyone to define a new message.  My recommendation is that that through 
one Standard resource record, one can define a set of properties (that are 
presumably related).  You define your core Plastic message; Alasdair, in a 
sepearate Standard record, defines his extended set.  Applications can 
either describe support for whole sets or individual properties.

I think it can work.

cheers,
Ray