From mgerlich at ipb-halle.de  Fri Feb 20 05:35:25 2009
From: mgerlich at ipb-halle.de (Michael Gerlich)
Date: Fri, 20 Feb 2009 11:35:25 +0100
Subject: [MOBY-dev] creating primary inputs from scratch
Message-ID: <499E876D.7050505@ipb-halle.de>

Hi all,

I want to create a simple JUnit test case that tests if all services 
we're offering (in both default and testing registry) are working. I'am 
stuck in creating primary inputs for datatypes other than Object, 
especially ArrayString, ArrayFloat and MSPeakRelList - all defined in 
both registries.

I modified this example
http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html#helloWorld

An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has two 
children mz and relInt, defining a peak.

Here is what I do in order to create such a datatype as input for a service:

MSPeakRelList msList = new MSPeakRelList();
       
MSPeakRel ms1 = new MSPeakRel();
ms1.set_mz(153.3);
ms1.set_relInt(316);
      
MSPeakRel ms2 = new MSPeakRel();
ms2.set_mz(273.069);
ms2.set_relInt(999);
    
MSPeakRel[] peaks = new MSPeakRel[2];
for (int i = 0; i < peaks.length; i++) {
      peaks[i] = new MSPeakRel();
}
peaks[0] = ms1;
peaks[1] = ms2;
msList.set_MSPeakRel(peaks);


The simple client uses the MobyRequest function setInput(). It's 
arguments are either of type MobyContentInstance or MobyDataInstance.
Now what am I supposed to do to correctly set msList as primary input to 
a service (MassBank_QSearch_Test, testing reg).

BTW, it has gotten quiet on the mailing lists...


Kind regards,

Michael

From markw at illuminae.com  Fri Feb 20 06:59:02 2009
From: markw at illuminae.com (Mark)
Date: Fri, 20 Feb 2009 03:59:02 -0800
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <499E876D.7050505@ipb-halle.de>
References: <499E876D.7050505@ipb-halle.de>
Message-ID: <op.upnfkovldeqt07@oldhome>

talk to Eddie!!   He's almost finished writing this...




On Fri, 20 Feb 2009 02:35:25 -0800, Michael Gerlich  
<mgerlich at ipb-halle.de> wrote:

> Hi all,
>
> I want to create a simple JUnit test case that tests if all services  
> we're offering (in both default and testing registry) are working. I'am  
> stuck in creating primary inputs for datatypes other than Object,  
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in  
> both registries.
>
> I modified this example
> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html#helloWorld
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has two  
> children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a  
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>        MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>       MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>     MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>       peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's  
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input to  
> a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From edward.kawas at gmail.com  Fri Feb 20 07:55:06 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 20 Feb 2009 04:55:06 -0800
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <op.upnfkovldeqt07@oldhome>
References: <499E876D.7050505@ipb-halle.de> <op.upnfkovldeqt07@oldhome>
Message-ID: <499ea830.0508d00a.28a7.4d5f@mx.google.com>

Hi Michael,

If you are interested in writing unit tests for your services, have you had
a chance to look at the following page?
http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/unit-te
sts-for-moby-services

There you will find how to write test cases for your services (using
dashboard) and then how to test the services once your test cases have been
written.

Let me know if you need any more information!

Eddie

-----Original Message-----

On Fri, 20 Feb 2009 02:35:25 -0800, Michael Gerlich  
<mgerlich at ipb-halle.de> wrote:

> Hi all,
>
> I want to create a simple JUnit test case that tests if all services  
> we're offering (in both default and testing registry) are working. I'am  
> stuck in creating primary inputs for datatypes other than Object,  
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in  
> both registries.
>
> I modified this example
>
http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.htm
l#helloWorld
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has two  
> children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a  
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>        MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>       MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>     MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>       peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's  
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input to  
> a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From vickymr at uma.es  Fri Feb 20 06:52:25 2009
From: vickymr at uma.es (Victoria Martin Requena)
Date: Fri, 20 Feb 2009 12:52:25 +0100
Subject: [MOBY-dev] jORCA application
Message-ID: <499E9979.4050907@uma.es>

Dear all,
We are glad to deploy jORCA, a standalone application aimed to 
facilitate web-services integration, and stronlgly focused on usability: 
searching and new discovering methods, workflows composition 
(Magallanes), objects edition (collections.. coming soon) , advanced 
methods for services invokation (error handling/mirroring/asynchronism), 
etc.

jORCA can connect to several web service metadata repositories 
(currently "access" engines are available for Moby-central 
(moby.ucalgary.ca), Moby central test (bioinfo.icapture.ubc.ca), IRRI 
Repository (cropwiki.irri.org) and INB repositories (INAB, Moby-dev,test 
respository)). Other repositories, including ACGT/Grid based enviroment 
using credential mechanishms for controlled access are also available, 
and we are finishing the access to WSDL description of EBI services.

Most of the jORCA functionalities are summarised in the attached 
document (jORCA-Flyer.pdf) and there is a guided-tour and some video 
tutorials in jORCA's web-page.

Software download and documentation are available at 
http://chirimoyo.ac.uma.es/jorca

We would be really happy to have your opinions, recommendations for 
improvements, bugs reporting, etc.

We hope all of you enjoy the application.

Kind regards,
Vicky
The Bitlab team (INB GNV-5 Integrated Bioinformatics node)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: jORCA-Flyer.pdf
Type: application/pdf
Size: 1143705 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090220/834c46af/attachment-0001.pdf>

From gordonp at ucalgary.ca  Fri Feb 20 11:39:52 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri, 20 Feb 2009 09:39:52 -0700
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <499E876D.7050505@ipb-halle.de>
References: <499E876D.7050505@ipb-halle.de>
Message-ID: <499EDCD8.7060005@ucalgary.ca>

Hi Michael,

Alas, MobyRequest does not work with the compiled datatypes of MoSeS, it 
uses the original Moby data type framework extending 
org.biomoby.shared.MobyData. 
The way to build you object is listed below. Please not e that you'll 
need to do a CVS update.  I just found and fixed a bug when the varargs 
c-tor is called with a null namespace.

import org.biomoby.client.*;
import org.biomoby.shared.*;
import org.biomoby.shared.data.*;

public class HelloMOBY2{
    public static void main(String[] args) throws Exception{
        // Find the service
        Central central = new 
CentralImpl("http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl");
        MobyService templateService = new 
MobyService("MassBank_QSearch_Test");
        MobyService[] validServices = central.findService(templateService);
        MobyRequest request = new MobyRequest(central);
        request.setService(validServices[0]);

        // Create the data
        MobyDataType MSPeakRelType = central.getDataType("MSPeakRel");
        MobyDataComposite peak1 = new MobyDataComposite(MSPeakRelType, 
null, null,  //type, ns, id
                                                        "mz", "153.3", 
"relInt", "316"); //members
        MobyDataComposite peak2 = new MobyDataComposite(MSPeakRelType, 
null, null,
                                                        "mz", "273.069", 
"relInt", "999");
        MobyDataComposite msList = new 
MobyDataComposite(central.getDataType("MSPeakRelList"),
                                                         "test", 
(String) null, null);
        msList.put("MSPeakRel", peak1);
        msList.put("MSPeakRel", peak2);
        request.setInput(msList);

        // Run the job and print the results
        MobyContentInstance contents = request.invokeService();
        MobyDataUtils.toXMLDocument(System.out, contents);
    }
}

Michael Gerlich wrote:
> Hi all,
>
> I want to create a simple JUnit test case that tests if all services 
> we're offering (in both default and testing registry) are working. 
> I'am stuck in creating primary inputs for datatypes other than Object, 
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in 
> both registries.
>
> I modified this example
> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html#helloWorld 
>
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has 
> two children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a 
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>       MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>      MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>    MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>      peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's 
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input 
> to a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>

From mgerlich at ipb-halle.de  Fri Feb 20 13:24:28 2009
From: mgerlich at ipb-halle.de (Gerlich, Michael)
Date: Fri, 20 Feb 2009 19:24:28 +0100
Subject: [MOBY-dev] creating primary inputs from scratch
References: <499E876D.7050505@ipb-halle.de> <499EDCD8.7060005@ucalgary.ca>
Message-ID: <9264FE63AD0A634995D25D233D701BAD011A9B50@ipb-exchange.ipb-halle.de>


Thanks for this, didn't thought it could be that easy :)

So Moses generated datatypes are only available when one writes the Biomoby
service implementation (for the skeleton) and uses all of the get and set
methods provided/generated by MoSeS, right?

Thanks again to all, I appreciate this very much.
Next step unit testing ;-)

Best wishes to all of you,
Michael


-----Urspr?ngliche Nachricht-----
Von:	moby-dev-bounces at lists.open-bio.org im Auftrag von Paul Gordon
Gesendet:	Fr 20.02.2009 17:39
An:	Core developer announcements
Cc:	
Betreff:	Re: [MOBY-dev] creating primary inputs from scratch

Hi Michael,

Alas, MobyRequest does not work with the compiled datatypes of MoSeS, it 
uses the original Moby data type framework extending 
org.biomoby.shared.MobyData. 
The way to build you object is listed below. Please not e that you'll 
need to do a CVS update.  I just found and fixed a bug when the varargs 
c-tor is called with a null namespace.

import org.biomoby.client.*;
import org.biomoby.shared.*;
import org.biomoby.shared.data.*;

public class HelloMOBY2{
    public static void main(String[] args) throws Exception{
        // Find the service
        Central central = new 
CentralImpl("http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.
pl");
        MobyService templateService = new 
MobyService("MassBank_QSearch_Test");
        MobyService[] validServices = central.findService(templateService);
        MobyRequest request = new MobyRequest(central);
        request.setService(validServices[0]);

        // Create the data
        MobyDataType MSPeakRelType = central.getDataType("MSPeakRel");
        MobyDataComposite peak1 = new MobyDataComposite(MSPeakRelType, 
null, null,  //type, ns, id
                                                        "mz", "153.3", 
"relInt", "316"); //members
        MobyDataComposite peak2 = new MobyDataComposite(MSPeakRelType, 
null, null,
                                                        "mz", "273.069", 
"relInt", "999");
        MobyDataComposite msList = new 
MobyDataComposite(central.getDataType("MSPeakRelList"),
                                                         "test", 
(String) null, null);
        msList.put("MSPeakRel", peak1);
        msList.put("MSPeakRel", peak2);
        request.setInput(msList);

        // Run the job and print the results
        MobyContentInstance contents = request.invokeService();
        MobyDataUtils.toXMLDocument(System.out, contents);
    }
}

Michael Gerlich wrote:
> Hi all,
>
> I want to create a simple JUnit test case that tests if all services 
> we're offering (in both default and testing registry) are working. 
> I'am stuck in creating primary inputs for datatypes other than Object, 
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in 
> both registries.
>
> I modified this example
>
http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html
#helloWorld 
>
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has 
> two children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a 
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>       MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>      MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>    MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>      peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's 
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input 
> to a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev





From gordonp at ucalgary.ca  Fri Feb 20 13:30:57 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri, 20 Feb 2009 11:30:57 -0700
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <9264FE63AD0A634995D25D233D701BAD011A9B50@ipb-exchange.ipb-halle.de>
References: <499E876D.7050505@ipb-halle.de> <499EDCD8.7060005@ucalgary.ca>
	<9264FE63AD0A634995D25D233D701BAD011A9B50@ipb-exchange.ipb-halle.de>
Message-ID: <499EF6E1.6050100@ucalgary.ca>

I think this is the phrase an API developer dreams about hearing :-)
> Thanks for this, didn't thought it could be that easy :)
>   
P.S. The list might be fairly quiet, but that's because we're working 
hard, not hardly working :-)

From julien.wollbrett at cirad.fr  Mon Feb 23 04:43:53 2009
From: julien.wollbrett at cirad.fr (Julien Wollbrett)
Date: Mon, 23 Feb 2009 10:43:53 +0100
Subject: [MOBY-dev] Problem to register a lot of datatypes
Message-ID: <49A26FD9.6010203@cirad.fr>

Hello,

I write a plugin to Prot?g?. It is writen in Java. This  plugin parse an 
OWL file (with Jena) store all OWL classes and these restrictions in a 
Mobydatatype Vector and try to register all datatypes.
I now store all datatypes informations into my Vector but when I try to 
register all datatypes to a central registry I have an error message. 
This message is writen for small number of datatypes I try to register.
The message is:

       *object failed to register due to failure during registration of 
ISA/HASA relationships.  Message returned was Object will have 
conflicting articleName hasSpiciness; Mild
*
For example this message is written when I try to register the class 
SundriedTomatoTopping which is a class of the Pizza example ontology 
(include to prot?g? examples).
When I show the toString() method for this class the result is:

Name:    SundriedTomatoTopping
Auth:    j.w at cirad.fr
Desc:    temporary test description (use when ontology class has no 
description)
Contact: cirad.fr
LSID:    
urn:lsid:biomoby.org:objectclass:SundriedTomatoTopping:2009-20-2T14-43-34Z
Parents: TomatoTopping
Children (only those registered here): *hasSpiciness (HAS) => Mild*

I don't know why I have a conflicting articleName. I have only one HAS 
relation. I have no problem with others datatype which has "HAS/HASA" 
relationships.
Is it possible that this conflict is because parent datatype 
(TomatoTopping) has the same HAS relationship?
The toString() method for the TomatoTopping datatype is:

Name:    TomatoTopping
Auth:    j.w at cirad.fr
Desc:    temporary test description (use when ontology class has no 
description)
Contact: cirad.fr
LSID:    urn:lsid:biomoby.org:objectclass:TomatoTopping:2009-20-2T14-43-34Z
Parents: VegetableTopping
Children (only those registered here): *hasSpiciness (HAS) => Mild

*Kind regards,

Julien Wollbrett*
*


From pieter.neerincx at gmail.com  Mon Feb 23 05:34:14 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Mon, 23 Feb 2009 11:34:14 +0100
Subject: [MOBY-dev] Problem to register a lot of datatypes
In-Reply-To: <49A26FD9.6010203@cirad.fr>
References: <49A26FD9.6010203@cirad.fr>
Message-ID: <922819EC-6066-4490-B752-1BF9F139A8C3@gmail.com>

Hi Julien,

On 23 Feb 2009, at 10:43, Julien Wollbrett wrote:

> Hello,
>
> I write a plugin to Prot?g?. It is writen in Java. This  plugin  
> parse an OWL file (with Jena) store all OWL classes and these  
> restrictions in a Mobydatatype Vector and try to register all  
> datatypes.
> I now store all datatypes informations into my Vector but when I try  
> to register all datatypes to a central registry I have an error  
> message. This message is writen for small number of datatypes I try  
> to register.
> The message is:
>
>      *object failed to register due to failure during registration  
> of ISA/HASA relationships.  Message returned was Object will have  
> conflicting articleName hasSpiciness; Mild
> *
> For example this message is written when I try to register the class  
> SundriedTomatoTopping which is a class of the Pizza example ontology  
> (include to prot?g? examples).
> When I show the toString() method for this class the result is:
>
> Name:    SundriedTomatoTopping
> Auth:    j.w at cirad.fr
> Desc:    temporary test description (use when ontology class has no  
> description)
> Contact: cirad.fr
> LSID:    urn:lsid:biomoby.org:objectclass:SundriedTomatoTopping:2009-20-2T14-43-34Z
> Parents: TomatoTopping
> Children (only those registered here): *hasSpiciness (HAS) => Mild*
>
> I don't know why I have a conflicting articleName. I have only one  
> HAS relation. I have no problem with others datatype which has "HAS/ 
> HASA" relationships.
> Is it possible that this conflict is because parent datatype  
> (TomatoTopping) has the same HAS relationship?

Yes, that appears to be the case. If SundriedTomatoTopping ISA  
TomatoTopping it will inherit the hasSpiciness child from the parent.  
You cannot specify another child with the same articleName attribute...

Cheers,

Pi

> The toString() method for the TomatoTopping datatype is:
>
> Name:    TomatoTopping
> Auth:    j.w at cirad.fr
> Desc:    temporary test description (use when ontology class has no  
> description)
> Contact: cirad.fr
> LSID:    urn:lsid:biomoby.org:objectclass:TomatoTopping:2009-20-2T14-43-34Z
> Parents: VegetableTopping
> Children (only those registered here): *hasSpiciness (HAS) => Mild
>
> *Kind regards,
>
> Julien Wollbrett*
> *
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------





From vickymr at uma.es  Mon Feb 23 04:37:54 2009
From: vickymr at uma.es (Victoria Martin Requena)
Date: Mon, 23 Feb 2009 10:37:54 +0100
Subject: [MOBY-dev] jORCA application
In-Reply-To: <499E9979.4050907@uma.es>
References: <499E9979.4050907@uma.es>
Message-ID: <49A26E72.5040804@uma.es>

Good morning,
There was a spelling mistake in jORCA Flyer, we attach the corrected 
version.

Kind regards,
Vicky

Victoria Martin Requena escribi?:
> Dear all,
> We are glad to deploy jORCA, a standalone application aimed to 
> facilitate web-services integration, and stronlgly focused on 
> usability: searching and new discovering methods, workflows 
> composition (Magallanes), objects edition (collections.. coming soon) 
> , advanced methods for services invokation (error 
> handling/mirroring/asynchronism), etc.
>
> jORCA can connect to several web service metadata repositories 
> (currently "access" engines are available for Moby-central 
> (moby.ucalgary.ca), Moby central test (bioinfo.icapture.ubc.ca), IRRI 
> Repository (cropwiki.irri.org) and INB repositories (INAB, 
> Moby-dev,test respository)). Other repositories, including ACGT/Grid 
> based enviroment using credential mechanishms for controlled access 
> are also available, and we are finishing the access to WSDL 
> description of EBI services.
>
> Most of the jORCA functionalities are summarised in the attached 
> document (jORCA-Flyer.pdf) and there is a guided-tour and some video 
> tutorials in jORCA's web-page.
>
> Software download and documentation are available at 
> http://chirimoyo.ac.uma.es/jorca
>
> We would be really happy to have your opinions, recommendations for 
> improvements, bugs reporting, etc.
>
> We hope all of you enjoy the application.
>
> Kind regards,
> Vicky
> The Bitlab team (INB GNV-5 Integrated Bioinformatics node)
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jORCA-Flyer.pdf
Type: application/pdf
Size: 1133395 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090223/f66658a6/attachment-0001.pdf>

From edward.kawas at gmail.com  Mon Feb 23 17:04:54 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 23 Feb 2009 14:04:54 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
Message-ID: <49a31d97.0e538c0a.1915.4402@mx.google.com>

Hello all,

Attached is a draft proposal describing asynchronous post services in moby.
It is very similar to the RFC for moby-async services, except that it is
HTTP POST and not SOAP based.

Be harsh but nice!

Eddie 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: async_post_services.pdf
Type: application/pdf
Size: 93200 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090223/b9cc7889/attachment-0001.pdf>

From pieter.neerincx at gmail.com  Mon Feb 23 17:34:31 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Mon, 23 Feb 2009 23:34:31 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a31d97.0e538c0a.1915.4402@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
Message-ID: <1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>

Hi Eddie,

Interesting! Yesterday I browsed the BioMoby site once more. It had  
been a while and noticed the CGI based services. Was wondering if  
these were the (in)famous REST based things. (Whenever we have a WS  
related meeting / symposium here in the Netherlands the discussion is  
doomed to result in a SOAP vs REST discussion in no time... Maybe  
battle is a more appropriate term than discussion :)). I was already  
wondering if these CGI based Moby services would also work for async  
stuff, but you beat me to it :). I'll have a look at the proposal, but  
it might take some time as I'm in the middle of submitting a PhD  
Thesis for final review...

Cheers,

Pi

On 23 Feb 2009, at 23:04, Edward Kawas wrote:

> Hello all,
>
> Attached is a draft proposal describing asynchronous post services  
> in moby.
> It is very similar to the RFC for moby-async services, except that  
> it is
> HTTP POST and not SOAP based.
>
> Be harsh but nice!
>
> Eddie
>
> < 
> async_post_services 
> .pdf>_______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------




From markw at illuminae.com  Mon Feb 23 17:35:23 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 23 Feb 2009 14:35:23 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
	<1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
Message-ID: <op.upts09linbznux@dd0710001l.icapture.ubc.ca>

On Mon, 23 Feb 2009 14:34:31 -0800, Pieter Neerincx  
<pieter.neerincx at gmail.com> wrote:


> but it might take some time as I'm in the middle of submitting a PhD  
> Thesis for final review...

Good luck Pieter!

Mark



-- 
Mark D Wilkinson, PI Bioinformatics
Assistant Professor, Medical Genetics
The James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research
Providence Heart + Lung Institute
University of British Columbia - St. Paul's Hospital
Vancouver, BC, Canada

From srramirez at uma.es  Tue Feb 24 12:44:00 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Feb 2009 18:44:00 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
	<1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
Message-ID: <49A431E0.5020006@uma.es>

Nice proposal Eddy. In a fast reading it looks similar to the Moby 
Asyncronous proposal which would facilitate the implementation of new 
services and clients (i.e., support for such kind of services in clients 
like jOrca would allow their combined use with traditional MOBY services).

will read with detail and comment
Best Regards, Sergio

Pieter Neerincx wrote:
> Hi Eddie,
>
> Interesting! Yesterday I browsed the BioMoby site once more. It had 
> been a while and noticed the CGI based services. Was wondering if 
> these were the (in)famous REST based things. (Whenever we have a WS 
> related meeting / symposium here in the Netherlands the discussion is 
> doomed to result in a SOAP vs REST discussion in no time... Maybe 
> battle is a more appropriate term than discussion :)). I was already 
> wondering if these CGI based Moby services would also work for async 
> stuff, but you beat me to it :). I'll have a look at the proposal, but 
> it might take some time as I'm in the middle of submitting a PhD 
> Thesis for final review...
>
> Cheers,
>
> Pi
>
> On 23 Feb 2009, at 23:04, Edward Kawas wrote:
>
>> Hello all,
>>
>> Attached is a draft proposal describing asynchronous post services in 
>> moby.
>> It is very similar to the RFC for moby-async services, except that it is
>> HTTP POST and not SOAP based.
>>
>> Be harsh but nice!
>>
>> Eddie
>>
>> <async_post_services.pdf>_______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone:  +31 (0)317-483 060
> mobile: +31 (0)6-143 66 783
> e-mail: pieter.neerincx at gmail.com
> skype:  pieter.online
> -------------------------------------------------------------
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>


-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 


From gordonp at ucalgary.ca  Tue Feb 24 13:17:06 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 24 Feb 2009 11:17:06 -0700
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a31d97.0e538c0a.1915.4402@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
Message-ID: <49A439A2.5080308@ucalgary.ca>

Hi Eddie,

Pardon my ignorance, I was quickly perusing the document, but in the 
document where you break down sample XML such as "Response from 
destroying the resource", how exact do you put that XML block in the 
header?  I though HTTP headers are usually name=value...

Edward Kawas wrote:
> Hello all,
>
> Attached is a draft proposal describing asynchronous post services in moby.
> It is very similar to the RFC for moby-async services, except that it is
> HTTP POST and not SOAP based.
>
> Be harsh but nice!
>
> Eddie 
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

From edward.kawas at gmail.com  Tue Feb 24 13:21:52 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 24 Feb 2009 10:21:52 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A439A2.5080308@ucalgary.ca>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
	<49A439A2.5080308@ucalgary.ca>
Message-ID: <49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>

Hi Paul,

I was thinking of just treating that XML doc as a string and placing that as
the value for the header with key biomoby-wsrf.

Do you think that will work?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:17 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi Eddie,

Pardon my ignorance, I was quickly perusing the document, but in the 
document where you break down sample XML such as "Response from 
destroying the resource", how exact do you put that XML block in the 
header?  I though HTTP headers are usually name=value...

Edward Kawas wrote:
> Hello all,
>
> Attached is a draft proposal describing asynchronous post services in
moby.
> It is very similar to the RFC for moby-async services, except that it is
> HTTP POST and not SOAP based.
>
> Be harsh but nice!
>
> Eddie 
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From gordonp at ucalgary.ca  Tue Feb 24 13:43:18 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 24 Feb 2009 11:43:18 -0700
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>
	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>
Message-ID: <49A43FC6.30303@ucalgary.ca>

According to RFC2616, which references RFC822 section 3.1, you can 
indeed have multi-line header field value, as long as each extra line 
starts with some linear white space.  Otherwise it'll think a new line 
is a new header (and probably a malformed one at that).  There is a 
standard for "folding" and "unfolding" such multi-line headers, which 
essential strips CR and LF out of the message on the receiving end.  I'm 
not sure how well this folding and unfolding protocol is handled by 
various servers and clients, but given that new lines will be stripped 
out on the receiving end anyway, should we say that the biomoby-wsrf 
field XML value should have no new lines, for maximum likelihood of 
transactional success?

Edward Kawas wrote:
> Hi Paul,
>
> I was thinking of just treating that XML doc as a string and placing that as
> the value for the header with key biomoby-wsrf.
>
> Do you think that will work?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:17 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi Eddie,
>
> Pardon my ignorance, I was quickly perusing the document, but in the 
> document where you break down sample XML such as "Response from 
> destroying the resource", how exact do you put that XML block in the 
> header?  I though HTTP headers are usually name=value...
>
> Edward Kawas wrote:
>   
>> Hello all,
>>
>> Attached is a draft proposal describing asynchronous post services in
>>     
> moby.
>   
>> It is very similar to the RFC for moby-async services, except that it is
>> HTTP POST and not SOAP based.
>>
>> Be harsh but nice!
>>
>> Eddie 
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   

From edward.kawas at gmail.com  Tue Feb 24 13:49:43 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 24 Feb 2009 10:49:43 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A43FC6.30303@ucalgary.ca>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>
	<49A43FC6.30303@ucalgary.ca>
Message-ID: <49a44158.14b48c0a.7a1d.1df9@mx.google.com>

You bring up a very good point. I think that we could either agree to use no
new lines. 

Another, less desirable, option might be to base64 encode the header... I
like your idea more though (I like sitting on the fence ...)

Eddie 

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:43 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

According to RFC2616, which references RFC822 section 3.1, you can 
indeed have multi-line header field value, as long as each extra line 
starts with some linear white space.  Otherwise it'll think a new line 
is a new header (and probably a malformed one at that).  There is a 
standard for "folding" and "unfolding" such multi-line headers, which 
essential strips CR and LF out of the message on the receiving end.  I'm 
not sure how well this folding and unfolding protocol is handled by 
various servers and clients, but given that new lines will be stripped 
out on the receiving end anyway, should we say that the biomoby-wsrf 
field XML value should have no new lines, for maximum likelihood of 
transactional success?

Edward Kawas wrote:
> Hi Paul,
>
> I was thinking of just treating that XML doc as a string and placing that
as
> the value for the header with key biomoby-wsrf.
>
> Do you think that will work?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:17 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi Eddie,
>
> Pardon my ignorance, I was quickly perusing the document, but in the 
> document where you break down sample XML such as "Response from 
> destroying the resource", how exact do you put that XML block in the 
> header?  I though HTTP headers are usually name=value...
>
> Edward Kawas wrote:
>   
>> Hello all,
>>
>> Attached is a draft proposal describing asynchronous post services in
>>     
> moby.
>   
>> It is very similar to the RFC for moby-async services, except that it is
>> HTTP POST and not SOAP based.
>>
>> Be harsh but nice!
>>
>> Eddie 
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From gordonp at ucalgary.ca  Tue Feb 24 13:57:05 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 24 Feb 2009 11:57:05 -0700
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a44158.14b48c0a.7a1d.1df9@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>
	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>
Message-ID: <49A44301.9030802@ucalgary.ca>

I vote for strongly encouraging no new lines in the XML, and warning 
implementers that it might crap out if they include any. I HATE base64 
encoding and decoding messages!  Kind of defeats the purpose of using 
XML in the message in the first place...

BTW, I can confirm after scouring the Web for info that lots of programs 
(e.g. Microsoft IIS, IBM Websphere) have run into problems with 
multi-line headers, even in the last couple of years.

Edward Kawas wrote:
> You bring up a very good point. I think that we could either agree to use no
> new lines. 
>
> Another, less desirable, option might be to base64 encode the header... I
> like your idea more though (I like sitting on the fence ...)
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:43 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> According to RFC2616, which references RFC822 section 3.1, you can 
> indeed have multi-line header field value, as long as each extra line 
> starts with some linear white space.  Otherwise it'll think a new line 
> is a new header (and probably a malformed one at that).  There is a 
> standard for "folding" and "unfolding" such multi-line headers, which 
> essential strips CR and LF out of the message on the receiving end.  I'm 
> not sure how well this folding and unfolding protocol is handled by 
> various servers and clients, but given that new lines will be stripped 
> out on the receiving end anyway, should we say that the biomoby-wsrf 
> field XML value should have no new lines, for maximum likelihood of 
> transactional success?
>
> Edward Kawas wrote:
>   
>> Hi Paul,
>>
>> I was thinking of just treating that XML doc as a string and placing that
>>     
> as
>   
>> the value for the header with key biomoby-wsrf.
>>
>> Do you think that will work?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:17 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> Hi Eddie,
>>
>> Pardon my ignorance, I was quickly perusing the document, but in the 
>> document where you break down sample XML such as "Response from 
>> destroying the resource", how exact do you put that XML block in the 
>> header?  I though HTTP headers are usually name=value...
>>
>> Edward Kawas wrote:
>>   
>>     
>>> Hello all,
>>>
>>> Attached is a draft proposal describing asynchronous post services in
>>>     
>>>       
>> moby.
>>   
>>     
>>> It is very similar to the RFC for moby-async services, except that it is
>>> HTTP POST and not SOAP based.
>>>
>>> Be harsh but nice!
>>>
>>> Eddie 
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>     
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   

From edward.kawas at gmail.com  Tue Feb 24 14:53:07 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 24 Feb 2009 11:53:07 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A44301.9030802@ucalgary.ca>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>
	<49A44301.9030802@ucalgary.ca>
Message-ID: <49a4503f.16538c0a.5fb0.0d70@mx.google.com>

Yeah, I just wanted to throw out the other option for consideration. Besides
encoding/decoding overhead, there is also a doubling of the message side if
we went that route. I agree, no new lines. 

Anyone with any objections?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:57 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

I vote for strongly encouraging no new lines in the XML, and warning 
implementers that it might crap out if they include any. I HATE base64 
encoding and decoding messages!  Kind of defeats the purpose of using 
XML in the message in the first place...

BTW, I can confirm after scouring the Web for info that lots of programs 
(e.g. Microsoft IIS, IBM Websphere) have run into problems with 
multi-line headers, even in the last couple of years.

Edward Kawas wrote:
> You bring up a very good point. I think that we could either agree to use
no
> new lines. 
>
> Another, less desirable, option might be to base64 encode the header... I
> like your idea more though (I like sitting on the fence ...)
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:43 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> According to RFC2616, which references RFC822 section 3.1, you can 
> indeed have multi-line header field value, as long as each extra line 
> starts with some linear white space.  Otherwise it'll think a new line 
> is a new header (and probably a malformed one at that).  There is a 
> standard for "folding" and "unfolding" such multi-line headers, which 
> essential strips CR and LF out of the message on the receiving end.  I'm 
> not sure how well this folding and unfolding protocol is handled by 
> various servers and clients, but given that new lines will be stripped 
> out on the receiving end anyway, should we say that the biomoby-wsrf 
> field XML value should have no new lines, for maximum likelihood of 
> transactional success?
>
> Edward Kawas wrote:
>   
>> Hi Paul,
>>
>> I was thinking of just treating that XML doc as a string and placing that
>>     
> as
>   
>> the value for the header with key biomoby-wsrf.
>>
>> Do you think that will work?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:17 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> Hi Eddie,
>>
>> Pardon my ignorance, I was quickly perusing the document, but in the 
>> document where you break down sample XML such as "Response from 
>> destroying the resource", how exact do you put that XML block in the 
>> header?  I though HTTP headers are usually name=value...
>>
>> Edward Kawas wrote:
>>   
>>     
>>> Hello all,
>>>
>>> Attached is a draft proposal describing asynchronous post services in
>>>     
>>>       
>> moby.
>>   
>>     
>>> It is very similar to the RFC for moby-async services, except that it is
>>> HTTP POST and not SOAP based.
>>>
>>> Be harsh but nice!
>>>
>>> Eddie 
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>     
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From jmfernandez at cnio.es  Tue Feb 24 18:45:44 2009
From: jmfernandez at cnio.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 25 Feb 2009 00:45:44 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a4503f.16538c0a.5fb0.0d70@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>
	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>
Message-ID: <49A486A8.1020003@cnio.es>

Hi everybody,
	yes, I also agree about no multi-line headers, because they could bring many
compatibility issues, and some "clever" intermediate firewall or proxy could
misunderstand them.

	Jos? Mar?a

Edward Kawas wrote:
> Yeah, I just wanted to throw out the other option for consideration. Besides
> encoding/decoding overhead, there is also a doubling of the message side if
> we went that route. I agree, no new lines. 
> 
> Anyone with any objections?
> 
> Eddie
> 
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:57 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
> 
> I vote for strongly encouraging no new lines in the XML, and warning 
> implementers that it might crap out if they include any. I HATE base64 
> encoding and decoding messages!  Kind of defeats the purpose of using 
> XML in the message in the first place...
> 
> BTW, I can confirm after scouring the Web for info that lots of programs 
> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
> multi-line headers, even in the last couple of years.
> 
> Edward Kawas wrote:
>> You bring up a very good point. I think that we could either agree to use
> no
>> new lines. 
>>
>> Another, less desirable, option might be to base64 encode the header... I
>> like your idea more though (I like sitting on the fence ...)
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:43 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> According to RFC2616, which references RFC822 section 3.1, you can 
>> indeed have multi-line header field value, as long as each extra line 
>> starts with some linear white space.  Otherwise it'll think a new line 
>> is a new header (and probably a malformed one at that).  There is a 
>> standard for "folding" and "unfolding" such multi-line headers, which 
>> essential strips CR and LF out of the message on the receiving end.  I'm 
>> not sure how well this folding and unfolding protocol is handled by 
>> various servers and clients, but given that new lines will be stripped 
>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>> field XML value should have no new lines, for maximum likelihood of 
>> transactional success?
>>
>> Edward Kawas wrote:
>>   
>>> Hi Paul,
>>>
>>> I was thinking of just treating that XML doc as a string and placing that
>>>     
>> as
>>   
>>> the value for the header with key biomoby-wsrf.
>>>
>>> Do you think that will work?
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:17 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> Hi Eddie,
>>>
>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>> document where you break down sample XML such as "Response from 
>>> destroying the resource", how exact do you put that XML block in the 
>>> header?  I though HTTP headers are usually name=value...
>>>
>>> Edward Kawas wrote:
>>>   
>>>     
>>>> Hello all,
>>>>
>>>> Attached is a draft proposal describing asynchronous post services in
>>>>     
>>>>       
>>> moby.
>>>   
>>>     
>>>> It is very similar to the RFC for moby-async services, except that it is
>>>> HTTP POST and not SOAP based.
>>>>
>>>> Be harsh but nice!
>>>>
>>>> Eddie 
>>>>   
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>     
>>>>       
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>     
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 

-- 
"There is no reason why anybody would want a computer in their home" -
	Ken Olson, founder of DEC 1977
"640K ought to be enough for anybody" - Bill Gates, 1981
"Nobody will ever outgrow a 20Mb hard drive." - ???

"Premature optimization is the root of all evil." - Donald Knuth

Jos? Mar?a Fern?ndez Gonz?lez
Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 3061)
e-mail: jmfernandez at cnio.es		Fax: (+34) 91 224 69 76
Unidad del Instituto Nacional de Bioinform?tica
Biolog?a Estructural y Biocomputaci?n	Structural Biology and Biocomputing
Centro Nacional de Investigaciones Oncol?gicas
C.P.: 28029				Zip Code: 28029
C/. Melchor Fern?ndez Almagro, 3	Madrid (Spain)

**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies.


From edward.kawas at gmail.com  Fri Feb 27 16:22:42 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 27 Feb 2009 13:22:42 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A486A8.1020003@cnio.es>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>
	<49A486A8.1020003@cnio.es>
Message-ID: <49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>

Another thing that I ran into today is that the HTTP header XML for polling,
requesting results, and destroying the job need a root element. What does
everyone think about wrapping the header as defined in the RFC with
<moby-wsrf></moby-wsrf>?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
Fern?ndez Gonz?lez
Sent: February-24-09 3:46 PM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi everybody,
	yes, I also agree about no multi-line headers, because they could
bring many
compatibility issues, and some "clever" intermediate firewall or proxy could
misunderstand them.

	Jos? Mar?a

Edward Kawas wrote:
> Yeah, I just wanted to throw out the other option for consideration.
Besides
> encoding/decoding overhead, there is also a doubling of the message side
if
> we went that route. I agree, no new lines. 
> 
> Anyone with any objections?
> 
> Eddie
> 
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:57 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
> 
> I vote for strongly encouraging no new lines in the XML, and warning 
> implementers that it might crap out if they include any. I HATE base64 
> encoding and decoding messages!  Kind of defeats the purpose of using 
> XML in the message in the first place...
> 
> BTW, I can confirm after scouring the Web for info that lots of programs 
> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
> multi-line headers, even in the last couple of years.
> 
> Edward Kawas wrote:
>> You bring up a very good point. I think that we could either agree to use
> no
>> new lines. 
>>
>> Another, less desirable, option might be to base64 encode the header... I
>> like your idea more though (I like sitting on the fence ...)
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:43 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> According to RFC2616, which references RFC822 section 3.1, you can 
>> indeed have multi-line header field value, as long as each extra line 
>> starts with some linear white space.  Otherwise it'll think a new line 
>> is a new header (and probably a malformed one at that).  There is a 
>> standard for "folding" and "unfolding" such multi-line headers, which 
>> essential strips CR and LF out of the message on the receiving end.  I'm 
>> not sure how well this folding and unfolding protocol is handled by 
>> various servers and clients, but given that new lines will be stripped 
>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>> field XML value should have no new lines, for maximum likelihood of 
>> transactional success?
>>
>> Edward Kawas wrote:
>>   
>>> Hi Paul,
>>>
>>> I was thinking of just treating that XML doc as a string and placing
that
>>>     
>> as
>>   
>>> the value for the header with key biomoby-wsrf.
>>>
>>> Do you think that will work?
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:17 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> Hi Eddie,
>>>
>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>> document where you break down sample XML such as "Response from 
>>> destroying the resource", how exact do you put that XML block in the 
>>> header?  I though HTTP headers are usually name=value...
>>>
>>> Edward Kawas wrote:
>>>   
>>>     
>>>> Hello all,
>>>>
>>>> Attached is a draft proposal describing asynchronous post services in
>>>>     
>>>>       
>>> moby.
>>>   
>>>     
>>>> It is very similar to the RFC for moby-async services, except that it
is
>>>> HTTP POST and not SOAP based.
>>>>
>>>> Be harsh but nice!
>>>>
>>>> Eddie 
>>>>   
>>>>
------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>     
>>>>       
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>     
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 

-- 
"There is no reason why anybody would want a computer in their home" -
	Ken Olson, founder of DEC 1977
"640K ought to be enough for anybody" - Bill Gates, 1981
"Nobody will ever outgrow a 20Mb hard drive." - ???

"Premature optimization is the root of all evil." - Donald Knuth

Jos? Mar?a Fern?ndez Gonz?lez
Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 3061)
e-mail: jmfernandez at cnio.es		Fax: (+34) 91 224 69 76
Unidad del Instituto Nacional de Bioinform?tica
Biolog?a Estructural y Biocomputaci?n	Structural Biology and Biocomputing
Centro Nacional de Investigaciones Oncol?gicas
C.P.: 28029				Zip Code: 28029
C/. Melchor Fern?ndez Almagro, 3	Madrid (Spain)

**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los
ficheros adjuntos, pueden contener informaci?n protegida para el uso
exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o
cualquier otro tipo de transmisi?n por parte de otra persona que no sea el
destinatario. Si usted recibe por error este correo, se ruega comunicarlo al
remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may
contain confidential and privileged information for the sole use of the
designated recipient named above. Distribution, reproduction or any other
use of this transmission by any party other than the intended recipient is
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From mgerlich at ipb-halle.de  Fri Feb 20 10:35:25 2009
From: mgerlich at ipb-halle.de (Michael Gerlich)
Date: Fri, 20 Feb 2009 11:35:25 +0100
Subject: [MOBY-dev] creating primary inputs from scratch
Message-ID: <499E876D.7050505@ipb-halle.de>

Hi all,

I want to create a simple JUnit test case that tests if all services 
we're offering (in both default and testing registry) are working. I'am 
stuck in creating primary inputs for datatypes other than Object, 
especially ArrayString, ArrayFloat and MSPeakRelList - all defined in 
both registries.

I modified this example
http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html#helloWorld

An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has two 
children mz and relInt, defining a peak.

Here is what I do in order to create such a datatype as input for a service:

MSPeakRelList msList = new MSPeakRelList();
       
MSPeakRel ms1 = new MSPeakRel();
ms1.set_mz(153.3);
ms1.set_relInt(316);
      
MSPeakRel ms2 = new MSPeakRel();
ms2.set_mz(273.069);
ms2.set_relInt(999);
    
MSPeakRel[] peaks = new MSPeakRel[2];
for (int i = 0; i < peaks.length; i++) {
      peaks[i] = new MSPeakRel();
}
peaks[0] = ms1;
peaks[1] = ms2;
msList.set_MSPeakRel(peaks);


The simple client uses the MobyRequest function setInput(). It's 
arguments are either of type MobyContentInstance or MobyDataInstance.
Now what am I supposed to do to correctly set msList as primary input to 
a service (MassBank_QSearch_Test, testing reg).

BTW, it has gotten quiet on the mailing lists...


Kind regards,

Michael


From markw at illuminae.com  Fri Feb 20 11:59:02 2009
From: markw at illuminae.com (Mark)
Date: Fri, 20 Feb 2009 03:59:02 -0800
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <499E876D.7050505@ipb-halle.de>
References: <499E876D.7050505@ipb-halle.de>
Message-ID: <op.upnfkovldeqt07@oldhome>

talk to Eddie!!   He's almost finished writing this...




On Fri, 20 Feb 2009 02:35:25 -0800, Michael Gerlich  
<mgerlich at ipb-halle.de> wrote:

> Hi all,
>
> I want to create a simple JUnit test case that tests if all services  
> we're offering (in both default and testing registry) are working. I'am  
> stuck in creating primary inputs for datatypes other than Object,  
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in  
> both registries.
>
> I modified this example
> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html#helloWorld
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has two  
> children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a  
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>        MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>       MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>     MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>       peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's  
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input to  
> a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


From edward.kawas at gmail.com  Fri Feb 20 12:55:06 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 20 Feb 2009 04:55:06 -0800
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <op.upnfkovldeqt07@oldhome>
References: <499E876D.7050505@ipb-halle.de> <op.upnfkovldeqt07@oldhome>
Message-ID: <499ea830.0508d00a.28a7.4d5f@mx.google.com>

Hi Michael,

If you are interested in writing unit tests for your services, have you had
a chance to look at the following page?
http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/unit-te
sts-for-moby-services

There you will find how to write test cases for your services (using
dashboard) and then how to test the services once your test cases have been
written.

Let me know if you need any more information!

Eddie

-----Original Message-----

On Fri, 20 Feb 2009 02:35:25 -0800, Michael Gerlich  
<mgerlich at ipb-halle.de> wrote:

> Hi all,
>
> I want to create a simple JUnit test case that tests if all services  
> we're offering (in both default and testing registry) are working. I'am  
> stuck in creating primary inputs for datatypes other than Object,  
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in  
> both registries.
>
> I modified this example
>
http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.htm
l#helloWorld
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has two  
> children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a  
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>        MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>       MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>     MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>       peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's  
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input to  
> a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From vickymr at uma.es  Fri Feb 20 11:52:25 2009
From: vickymr at uma.es (Victoria Martin Requena)
Date: Fri, 20 Feb 2009 12:52:25 +0100
Subject: [MOBY-dev] jORCA application
Message-ID: <499E9979.4050907@uma.es>

Dear all,
We are glad to deploy jORCA, a standalone application aimed to 
facilitate web-services integration, and stronlgly focused on usability: 
searching and new discovering methods, workflows composition 
(Magallanes), objects edition (collections.. coming soon) , advanced 
methods for services invokation (error handling/mirroring/asynchronism), 
etc.

jORCA can connect to several web service metadata repositories 
(currently "access" engines are available for Moby-central 
(moby.ucalgary.ca), Moby central test (bioinfo.icapture.ubc.ca), IRRI 
Repository (cropwiki.irri.org) and INB repositories (INAB, Moby-dev,test 
respository)). Other repositories, including ACGT/Grid based enviroment 
using credential mechanishms for controlled access are also available, 
and we are finishing the access to WSDL description of EBI services.

Most of the jORCA functionalities are summarised in the attached 
document (jORCA-Flyer.pdf) and there is a guided-tour and some video 
tutorials in jORCA's web-page.

Software download and documentation are available at 
http://chirimoyo.ac.uma.es/jorca

We would be really happy to have your opinions, recommendations for 
improvements, bugs reporting, etc.

We hope all of you enjoy the application.

Kind regards,
Vicky
The Bitlab team (INB GNV-5 Integrated Bioinformatics node)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: jORCA-Flyer.pdf
Type: application/pdf
Size: 1143705 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090220/834c46af/attachment-0002.pdf>

From gordonp at ucalgary.ca  Fri Feb 20 16:39:52 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri, 20 Feb 2009 09:39:52 -0700
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <499E876D.7050505@ipb-halle.de>
References: <499E876D.7050505@ipb-halle.de>
Message-ID: <499EDCD8.7060005@ucalgary.ca>

Hi Michael,

Alas, MobyRequest does not work with the compiled datatypes of MoSeS, it 
uses the original Moby data type framework extending 
org.biomoby.shared.MobyData. 
The way to build you object is listed below. Please not e that you'll 
need to do a CVS update.  I just found and fixed a bug when the varargs 
c-tor is called with a null namespace.

import org.biomoby.client.*;
import org.biomoby.shared.*;
import org.biomoby.shared.data.*;

public class HelloMOBY2{
    public static void main(String[] args) throws Exception{
        // Find the service
        Central central = new 
CentralImpl("http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.pl");
        MobyService templateService = new 
MobyService("MassBank_QSearch_Test");
        MobyService[] validServices = central.findService(templateService);
        MobyRequest request = new MobyRequest(central);
        request.setService(validServices[0]);

        // Create the data
        MobyDataType MSPeakRelType = central.getDataType("MSPeakRel");
        MobyDataComposite peak1 = new MobyDataComposite(MSPeakRelType, 
null, null,  //type, ns, id
                                                        "mz", "153.3", 
"relInt", "316"); //members
        MobyDataComposite peak2 = new MobyDataComposite(MSPeakRelType, 
null, null,
                                                        "mz", "273.069", 
"relInt", "999");
        MobyDataComposite msList = new 
MobyDataComposite(central.getDataType("MSPeakRelList"),
                                                         "test", 
(String) null, null);
        msList.put("MSPeakRel", peak1);
        msList.put("MSPeakRel", peak2);
        request.setInput(msList);

        // Run the job and print the results
        MobyContentInstance contents = request.invokeService();
        MobyDataUtils.toXMLDocument(System.out, contents);
    }
}

Michael Gerlich wrote:
> Hi all,
>
> I want to create a simple JUnit test case that tests if all services 
> we're offering (in both default and testing registry) are working. 
> I'am stuck in creating primary inputs for datatypes other than Object, 
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in 
> both registries.
>
> I modified this example
> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html#helloWorld 
>
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has 
> two children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a 
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>       MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>      MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>    MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>      peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's 
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input 
> to a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>


From mgerlich at ipb-halle.de  Fri Feb 20 18:24:28 2009
From: mgerlich at ipb-halle.de (Gerlich, Michael)
Date: Fri, 20 Feb 2009 19:24:28 +0100
Subject: [MOBY-dev] creating primary inputs from scratch
References: <499E876D.7050505@ipb-halle.de> <499EDCD8.7060005@ucalgary.ca>
Message-ID: <9264FE63AD0A634995D25D233D701BAD011A9B50@ipb-exchange.ipb-halle.de>


Thanks for this, didn't thought it could be that easy :)

So Moses generated datatypes are only available when one writes the Biomoby
service implementation (for the skeleton) and uses all of the get and set
methods provided/generated by MoSeS, right?

Thanks again to all, I appreciate this very much.
Next step unit testing ;-)

Best wishes to all of you,
Michael


-----Urspr?ngliche Nachricht-----
Von:	moby-dev-bounces at lists.open-bio.org im Auftrag von Paul Gordon
Gesendet:	Fr 20.02.2009 17:39
An:	Core developer announcements
Cc:	
Betreff:	Re: [MOBY-dev] creating primary inputs from scratch

Hi Michael,

Alas, MobyRequest does not work with the compiled datatypes of MoSeS, it 
uses the original Moby data type framework extending 
org.biomoby.shared.MobyData. 
The way to build you object is listed below. Please not e that you'll 
need to do a CVS update.  I just found and fixed a bug when the varargs 
c-tor is called with a null namespace.

import org.biomoby.client.*;
import org.biomoby.shared.*;
import org.biomoby.shared.data.*;

public class HelloMOBY2{
    public static void main(String[] args) throws Exception{
        // Find the service
        Central central = new 
CentralImpl("http://bioinfo.icapture.ubc.ca/cgi-bin/mobycentral/MOBY-Central.
pl");
        MobyService templateService = new 
MobyService("MassBank_QSearch_Test");
        MobyService[] validServices = central.findService(templateService);
        MobyRequest request = new MobyRequest(central);
        request.setService(validServices[0]);

        // Create the data
        MobyDataType MSPeakRelType = central.getDataType("MSPeakRel");
        MobyDataComposite peak1 = new MobyDataComposite(MSPeakRelType, 
null, null,  //type, ns, id
                                                        "mz", "153.3", 
"relInt", "316"); //members
        MobyDataComposite peak2 = new MobyDataComposite(MSPeakRelType, 
null, null,
                                                        "mz", "273.069", 
"relInt", "999");
        MobyDataComposite msList = new 
MobyDataComposite(central.getDataType("MSPeakRelList"),
                                                         "test", 
(String) null, null);
        msList.put("MSPeakRel", peak1);
        msList.put("MSPeakRel", peak2);
        request.setInput(msList);

        // Run the job and print the results
        MobyContentInstance contents = request.invokeService();
        MobyDataUtils.toXMLDocument(System.out, contents);
    }
}

Michael Gerlich wrote:
> Hi all,
>
> I want to create a simple JUnit test case that tests if all services 
> we're offering (in both default and testing registry) are working. 
> I'am stuck in creating primary inputs for datatypes other than Object, 
> especially ArrayString, ArrayFloat and MSPeakRelList - all defined in 
> both registries.
>
> I modified this example
>
http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/SimpleClient.html
#helloWorld 
>
>
> An MSPeakRelList is a list/array of MSPeakRel members. MSPeakRel has 
> two children mz and relInt, defining a peak.
>
> Here is what I do in order to create such a datatype as input for a 
> service:
>
> MSPeakRelList msList = new MSPeakRelList();
>       MSPeakRel ms1 = new MSPeakRel();
> ms1.set_mz(153.3);
> ms1.set_relInt(316);
>      MSPeakRel ms2 = new MSPeakRel();
> ms2.set_mz(273.069);
> ms2.set_relInt(999);
>    MSPeakRel[] peaks = new MSPeakRel[2];
> for (int i = 0; i < peaks.length; i++) {
>      peaks[i] = new MSPeakRel();
> }
> peaks[0] = ms1;
> peaks[1] = ms2;
> msList.set_MSPeakRel(peaks);
>
>
> The simple client uses the MobyRequest function setInput(). It's 
> arguments are either of type MobyContentInstance or MobyDataInstance.
> Now what am I supposed to do to correctly set msList as primary input 
> to a service (MassBank_QSearch_Test, testing reg).
>
> BTW, it has gotten quiet on the mailing lists...
>
>
> Kind regards,
>
> Michael
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev






From gordonp at ucalgary.ca  Fri Feb 20 18:30:57 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Fri, 20 Feb 2009 11:30:57 -0700
Subject: [MOBY-dev] creating primary inputs from scratch
In-Reply-To: <9264FE63AD0A634995D25D233D701BAD011A9B50@ipb-exchange.ipb-halle.de>
References: <499E876D.7050505@ipb-halle.de> <499EDCD8.7060005@ucalgary.ca>
	<9264FE63AD0A634995D25D233D701BAD011A9B50@ipb-exchange.ipb-halle.de>
Message-ID: <499EF6E1.6050100@ucalgary.ca>

I think this is the phrase an API developer dreams about hearing :-)
> Thanks for this, didn't thought it could be that easy :)
>   
P.S. The list might be fairly quiet, but that's because we're working 
hard, not hardly working :-)


From julien.wollbrett at cirad.fr  Mon Feb 23 09:43:53 2009
From: julien.wollbrett at cirad.fr (Julien Wollbrett)
Date: Mon, 23 Feb 2009 10:43:53 +0100
Subject: [MOBY-dev] Problem to register a lot of datatypes
Message-ID: <49A26FD9.6010203@cirad.fr>

Hello,

I write a plugin to Prot?g?. It is writen in Java. This  plugin parse an 
OWL file (with Jena) store all OWL classes and these restrictions in a 
Mobydatatype Vector and try to register all datatypes.
I now store all datatypes informations into my Vector but when I try to 
register all datatypes to a central registry I have an error message. 
This message is writen for small number of datatypes I try to register.
The message is:

       *object failed to register due to failure during registration of 
ISA/HASA relationships.  Message returned was Object will have 
conflicting articleName hasSpiciness; Mild
*
For example this message is written when I try to register the class 
SundriedTomatoTopping which is a class of the Pizza example ontology 
(include to prot?g? examples).
When I show the toString() method for this class the result is:

Name:    SundriedTomatoTopping
Auth:    j.w at cirad.fr
Desc:    temporary test description (use when ontology class has no 
description)
Contact: cirad.fr
LSID:    
urn:lsid:biomoby.org:objectclass:SundriedTomatoTopping:2009-20-2T14-43-34Z
Parents: TomatoTopping
Children (only those registered here): *hasSpiciness (HAS) => Mild*

I don't know why I have a conflicting articleName. I have only one HAS 
relation. I have no problem with others datatype which has "HAS/HASA" 
relationships.
Is it possible that this conflict is because parent datatype 
(TomatoTopping) has the same HAS relationship?
The toString() method for the TomatoTopping datatype is:

Name:    TomatoTopping
Auth:    j.w at cirad.fr
Desc:    temporary test description (use when ontology class has no 
description)
Contact: cirad.fr
LSID:    urn:lsid:biomoby.org:objectclass:TomatoTopping:2009-20-2T14-43-34Z
Parents: VegetableTopping
Children (only those registered here): *hasSpiciness (HAS) => Mild

*Kind regards,

Julien Wollbrett*
*



From pieter.neerincx at gmail.com  Mon Feb 23 10:34:14 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Mon, 23 Feb 2009 11:34:14 +0100
Subject: [MOBY-dev] Problem to register a lot of datatypes
In-Reply-To: <49A26FD9.6010203@cirad.fr>
References: <49A26FD9.6010203@cirad.fr>
Message-ID: <922819EC-6066-4490-B752-1BF9F139A8C3@gmail.com>

Hi Julien,

On 23 Feb 2009, at 10:43, Julien Wollbrett wrote:

> Hello,
>
> I write a plugin to Prot?g?. It is writen in Java. This  plugin  
> parse an OWL file (with Jena) store all OWL classes and these  
> restrictions in a Mobydatatype Vector and try to register all  
> datatypes.
> I now store all datatypes informations into my Vector but when I try  
> to register all datatypes to a central registry I have an error  
> message. This message is writen for small number of datatypes I try  
> to register.
> The message is:
>
>      *object failed to register due to failure during registration  
> of ISA/HASA relationships.  Message returned was Object will have  
> conflicting articleName hasSpiciness; Mild
> *
> For example this message is written when I try to register the class  
> SundriedTomatoTopping which is a class of the Pizza example ontology  
> (include to prot?g? examples).
> When I show the toString() method for this class the result is:
>
> Name:    SundriedTomatoTopping
> Auth:    j.w at cirad.fr
> Desc:    temporary test description (use when ontology class has no  
> description)
> Contact: cirad.fr
> LSID:    urn:lsid:biomoby.org:objectclass:SundriedTomatoTopping:2009-20-2T14-43-34Z
> Parents: TomatoTopping
> Children (only those registered here): *hasSpiciness (HAS) => Mild*
>
> I don't know why I have a conflicting articleName. I have only one  
> HAS relation. I have no problem with others datatype which has "HAS/ 
> HASA" relationships.
> Is it possible that this conflict is because parent datatype  
> (TomatoTopping) has the same HAS relationship?

Yes, that appears to be the case. If SundriedTomatoTopping ISA  
TomatoTopping it will inherit the hasSpiciness child from the parent.  
You cannot specify another child with the same articleName attribute...

Cheers,

Pi

> The toString() method for the TomatoTopping datatype is:
>
> Name:    TomatoTopping
> Auth:    j.w at cirad.fr
> Desc:    temporary test description (use when ontology class has no  
> description)
> Contact: cirad.fr
> LSID:    urn:lsid:biomoby.org:objectclass:TomatoTopping:2009-20-2T14-43-34Z
> Parents: VegetableTopping
> Children (only those registered here): *hasSpiciness (HAS) => Mild
>
> *Kind regards,
>
> Julien Wollbrett*
> *
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------






From vickymr at uma.es  Mon Feb 23 09:37:54 2009
From: vickymr at uma.es (Victoria Martin Requena)
Date: Mon, 23 Feb 2009 10:37:54 +0100
Subject: [MOBY-dev] jORCA application
In-Reply-To: <499E9979.4050907@uma.es>
References: <499E9979.4050907@uma.es>
Message-ID: <49A26E72.5040804@uma.es>

Good morning,
There was a spelling mistake in jORCA Flyer, we attach the corrected 
version.

Kind regards,
Vicky

Victoria Martin Requena escribi?:
> Dear all,
> We are glad to deploy jORCA, a standalone application aimed to 
> facilitate web-services integration, and stronlgly focused on 
> usability: searching and new discovering methods, workflows 
> composition (Magallanes), objects edition (collections.. coming soon) 
> , advanced methods for services invokation (error 
> handling/mirroring/asynchronism), etc.
>
> jORCA can connect to several web service metadata repositories 
> (currently "access" engines are available for Moby-central 
> (moby.ucalgary.ca), Moby central test (bioinfo.icapture.ubc.ca), IRRI 
> Repository (cropwiki.irri.org) and INB repositories (INAB, 
> Moby-dev,test respository)). Other repositories, including ACGT/Grid 
> based enviroment using credential mechanishms for controlled access 
> are also available, and we are finishing the access to WSDL 
> description of EBI services.
>
> Most of the jORCA functionalities are summarised in the attached 
> document (jORCA-Flyer.pdf) and there is a guided-tour and some video 
> tutorials in jORCA's web-page.
>
> Software download and documentation are available at 
> http://chirimoyo.ac.uma.es/jorca
>
> We would be really happy to have your opinions, recommendations for 
> improvements, bugs reporting, etc.
>
> We hope all of you enjoy the application.
>
> Kind regards,
> Vicky
> The Bitlab team (INB GNV-5 Integrated Bioinformatics node)
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jORCA-Flyer.pdf
Type: application/pdf
Size: 1133395 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090223/f66658a6/attachment-0002.pdf>

From edward.kawas at gmail.com  Mon Feb 23 22:04:54 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Mon, 23 Feb 2009 14:04:54 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
Message-ID: <49a31d97.0e538c0a.1915.4402@mx.google.com>

Hello all,

Attached is a draft proposal describing asynchronous post services in moby.
It is very similar to the RFC for moby-async services, except that it is
HTTP POST and not SOAP based.

Be harsh but nice!

Eddie 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: async_post_services.pdf
Type: application/pdf
Size: 93200 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20090223/b9cc7889/attachment-0002.pdf>

From pieter.neerincx at gmail.com  Mon Feb 23 22:34:31 2009
From: pieter.neerincx at gmail.com (Pieter Neerincx)
Date: Mon, 23 Feb 2009 23:34:31 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a31d97.0e538c0a.1915.4402@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
Message-ID: <1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>

Hi Eddie,

Interesting! Yesterday I browsed the BioMoby site once more. It had  
been a while and noticed the CGI based services. Was wondering if  
these were the (in)famous REST based things. (Whenever we have a WS  
related meeting / symposium here in the Netherlands the discussion is  
doomed to result in a SOAP vs REST discussion in no time... Maybe  
battle is a more appropriate term than discussion :)). I was already  
wondering if these CGI based Moby services would also work for async  
stuff, but you beat me to it :). I'll have a look at the proposal, but  
it might take some time as I'm in the middle of submitting a PhD  
Thesis for final review...

Cheers,

Pi

On 23 Feb 2009, at 23:04, Edward Kawas wrote:

> Hello all,
>
> Attached is a draft proposal describing asynchronous post services  
> in moby.
> It is very similar to the RFC for moby-async services, except that  
> it is
> HTTP POST and not SOAP based.
>
> Be harsh but nice!
>
> Eddie
>
> < 
> async_post_services 
> .pdf>_______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev

-------------------------------------------------------------
Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034

Dreijenlaan 3
6703 HA Wageningen
The Netherlands

phone:  +31 (0)317-483 060
mobile: +31 (0)6-143 66 783
e-mail: pieter.neerincx at gmail.com
skype:  pieter.online
-------------------------------------------------------------





From markw at illuminae.com  Mon Feb 23 22:35:23 2009
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 23 Feb 2009 14:35:23 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
	<1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
Message-ID: <op.upts09linbznux@dd0710001l.icapture.ubc.ca>

On Mon, 23 Feb 2009 14:34:31 -0800, Pieter Neerincx  
<pieter.neerincx at gmail.com> wrote:


> but it might take some time as I'm in the middle of submitting a PhD  
> Thesis for final review...

Good luck Pieter!

Mark



-- 
Mark D Wilkinson, PI Bioinformatics
Assistant Professor, Medical Genetics
The James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research
Providence Heart + Lung Institute
University of British Columbia - St. Paul's Hospital
Vancouver, BC, Canada


From srramirez at uma.es  Tue Feb 24 17:44:00 2009
From: srramirez at uma.es (Sergio Ramirez Ramirez)
Date: Tue, 24 Feb 2009 18:44:00 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
	<1526B3F7-DE5C-4095-BA26-97420C28DE15@gmail.com>
Message-ID: <49A431E0.5020006@uma.es>

Nice proposal Eddy. In a fast reading it looks similar to the Moby 
Asyncronous proposal which would facilitate the implementation of new 
services and clients (i.e., support for such kind of services in clients 
like jOrca would allow their combined use with traditional MOBY services).

will read with detail and comment
Best Regards, Sergio

Pieter Neerincx wrote:
> Hi Eddie,
>
> Interesting! Yesterday I browsed the BioMoby site once more. It had 
> been a while and noticed the CGI based services. Was wondering if 
> these were the (in)famous REST based things. (Whenever we have a WS 
> related meeting / symposium here in the Netherlands the discussion is 
> doomed to result in a SOAP vs REST discussion in no time... Maybe 
> battle is a more appropriate term than discussion :)). I was already 
> wondering if these CGI based Moby services would also work for async 
> stuff, but you beat me to it :). I'll have a look at the proposal, but 
> it might take some time as I'm in the middle of submitting a PhD 
> Thesis for final review...
>
> Cheers,
>
> Pi
>
> On 23 Feb 2009, at 23:04, Edward Kawas wrote:
>
>> Hello all,
>>
>> Attached is a draft proposal describing asynchronous post services in 
>> moby.
>> It is very similar to the RFC for moby-async services, except that it is
>> HTTP POST and not SOAP based.
>>
>> Be harsh but nice!
>>
>> Eddie
>>
>> <async_post_services.pdf>_______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> -------------------------------------------------------------
> Wageningen University and Research centre (WUR)
> Laboratory of Bioinformatics
> Transitorium (building 312) room 1034
>
> Dreijenlaan 3
> 6703 HA Wageningen
> The Netherlands
>
> phone:  +31 (0)317-483 060
> mobile: +31 (0)6-143 66 783
> e-mail: pieter.neerincx at gmail.com
> skype:  pieter.online
> -------------------------------------------------------------
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>


-- 
Sergio Ram?rez Ram?rez
Instituto Nacional de Bioinform?tica (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 M?laga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune 



From gordonp at ucalgary.ca  Tue Feb 24 18:17:06 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 24 Feb 2009 11:17:06 -0700
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a31d97.0e538c0a.1915.4402@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
Message-ID: <49A439A2.5080308@ucalgary.ca>

Hi Eddie,

Pardon my ignorance, I was quickly perusing the document, but in the 
document where you break down sample XML such as "Response from 
destroying the resource", how exact do you put that XML block in the 
header?  I though HTTP headers are usually name=value...

Edward Kawas wrote:
> Hello all,
>
> Attached is a draft proposal describing asynchronous post services in moby.
> It is very similar to the RFC for moby-async services, except that it is
> HTTP POST and not SOAP based.
>
> Be harsh but nice!
>
> Eddie 
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev


From edward.kawas at gmail.com  Tue Feb 24 18:21:52 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 24 Feb 2009 10:21:52 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A439A2.5080308@ucalgary.ca>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>
	<49A439A2.5080308@ucalgary.ca>
Message-ID: <49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>

Hi Paul,

I was thinking of just treating that XML doc as a string and placing that as
the value for the header with key biomoby-wsrf.

Do you think that will work?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:17 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi Eddie,

Pardon my ignorance, I was quickly perusing the document, but in the 
document where you break down sample XML such as "Response from 
destroying the resource", how exact do you put that XML block in the 
header?  I though HTTP headers are usually name=value...

Edward Kawas wrote:
> Hello all,
>
> Attached is a draft proposal describing asynchronous post services in
moby.
> It is very similar to the RFC for moby-async services, except that it is
> HTTP POST and not SOAP based.
>
> Be harsh but nice!
>
> Eddie 
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From gordonp at ucalgary.ca  Tue Feb 24 18:43:18 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 24 Feb 2009 11:43:18 -0700
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>
	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>
Message-ID: <49A43FC6.30303@ucalgary.ca>

According to RFC2616, which references RFC822 section 3.1, you can 
indeed have multi-line header field value, as long as each extra line 
starts with some linear white space.  Otherwise it'll think a new line 
is a new header (and probably a malformed one at that).  There is a 
standard for "folding" and "unfolding" such multi-line headers, which 
essential strips CR and LF out of the message on the receiving end.  I'm 
not sure how well this folding and unfolding protocol is handled by 
various servers and clients, but given that new lines will be stripped 
out on the receiving end anyway, should we say that the biomoby-wsrf 
field XML value should have no new lines, for maximum likelihood of 
transactional success?

Edward Kawas wrote:
> Hi Paul,
>
> I was thinking of just treating that XML doc as a string and placing that as
> the value for the header with key biomoby-wsrf.
>
> Do you think that will work?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:17 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi Eddie,
>
> Pardon my ignorance, I was quickly perusing the document, but in the 
> document where you break down sample XML such as "Response from 
> destroying the resource", how exact do you put that XML block in the 
> header?  I though HTTP headers are usually name=value...
>
> Edward Kawas wrote:
>   
>> Hello all,
>>
>> Attached is a draft proposal describing asynchronous post services in
>>     
> moby.
>   
>> It is very similar to the RFC for moby-async services, except that it is
>> HTTP POST and not SOAP based.
>>
>> Be harsh but nice!
>>
>> Eddie 
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   


From edward.kawas at gmail.com  Tue Feb 24 18:49:43 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 24 Feb 2009 10:49:43 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A43FC6.30303@ucalgary.ca>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>
	<49A43FC6.30303@ucalgary.ca>
Message-ID: <49a44158.14b48c0a.7a1d.1df9@mx.google.com>

You bring up a very good point. I think that we could either agree to use no
new lines. 

Another, less desirable, option might be to base64 encode the header... I
like your idea more though (I like sitting on the fence ...)

Eddie 

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:43 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

According to RFC2616, which references RFC822 section 3.1, you can 
indeed have multi-line header field value, as long as each extra line 
starts with some linear white space.  Otherwise it'll think a new line 
is a new header (and probably a malformed one at that).  There is a 
standard for "folding" and "unfolding" such multi-line headers, which 
essential strips CR and LF out of the message on the receiving end.  I'm 
not sure how well this folding and unfolding protocol is handled by 
various servers and clients, but given that new lines will be stripped 
out on the receiving end anyway, should we say that the biomoby-wsrf 
field XML value should have no new lines, for maximum likelihood of 
transactional success?

Edward Kawas wrote:
> Hi Paul,
>
> I was thinking of just treating that XML doc as a string and placing that
as
> the value for the header with key biomoby-wsrf.
>
> Do you think that will work?
>
> Eddie
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:17 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> Hi Eddie,
>
> Pardon my ignorance, I was quickly perusing the document, but in the 
> document where you break down sample XML such as "Response from 
> destroying the resource", how exact do you put that XML block in the 
> header?  I though HTTP headers are usually name=value...
>
> Edward Kawas wrote:
>   
>> Hello all,
>>
>> Attached is a draft proposal describing asynchronous post services in
>>     
> moby.
>   
>> It is very similar to the RFC for moby-async services, except that it is
>> HTTP POST and not SOAP based.
>>
>> Be harsh but nice!
>>
>> Eddie 
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From gordonp at ucalgary.ca  Tue Feb 24 18:57:05 2009
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Tue, 24 Feb 2009 11:57:05 -0700
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a44158.14b48c0a.7a1d.1df9@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>
	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>
Message-ID: <49A44301.9030802@ucalgary.ca>

I vote for strongly encouraging no new lines in the XML, and warning 
implementers that it might crap out if they include any. I HATE base64 
encoding and decoding messages!  Kind of defeats the purpose of using 
XML in the message in the first place...

BTW, I can confirm after scouring the Web for info that lots of programs 
(e.g. Microsoft IIS, IBM Websphere) have run into problems with 
multi-line headers, even in the last couple of years.

Edward Kawas wrote:
> You bring up a very good point. I think that we could either agree to use no
> new lines. 
>
> Another, less desirable, option might be to base64 encode the header... I
> like your idea more though (I like sitting on the fence ...)
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:43 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> According to RFC2616, which references RFC822 section 3.1, you can 
> indeed have multi-line header field value, as long as each extra line 
> starts with some linear white space.  Otherwise it'll think a new line 
> is a new header (and probably a malformed one at that).  There is a 
> standard for "folding" and "unfolding" such multi-line headers, which 
> essential strips CR and LF out of the message on the receiving end.  I'm 
> not sure how well this folding and unfolding protocol is handled by 
> various servers and clients, but given that new lines will be stripped 
> out on the receiving end anyway, should we say that the biomoby-wsrf 
> field XML value should have no new lines, for maximum likelihood of 
> transactional success?
>
> Edward Kawas wrote:
>   
>> Hi Paul,
>>
>> I was thinking of just treating that XML doc as a string and placing that
>>     
> as
>   
>> the value for the header with key biomoby-wsrf.
>>
>> Do you think that will work?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:17 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> Hi Eddie,
>>
>> Pardon my ignorance, I was quickly perusing the document, but in the 
>> document where you break down sample XML such as "Response from 
>> destroying the resource", how exact do you put that XML block in the 
>> header?  I though HTTP headers are usually name=value...
>>
>> Edward Kawas wrote:
>>   
>>     
>>> Hello all,
>>>
>>> Attached is a draft proposal describing asynchronous post services in
>>>     
>>>       
>> moby.
>>   
>>     
>>> It is very similar to the RFC for moby-async services, except that it is
>>> HTTP POST and not SOAP based.
>>>
>>> Be harsh but nice!
>>>
>>> Eddie 
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>     
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   


From edward.kawas at gmail.com  Tue Feb 24 19:53:07 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Tue, 24 Feb 2009 11:53:07 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A44301.9030802@ucalgary.ca>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>
	<49A44301.9030802@ucalgary.ca>
Message-ID: <49a4503f.16538c0a.5fb0.0d70@mx.google.com>

Yeah, I just wanted to throw out the other option for consideration. Besides
encoding/decoding overhead, there is also a doubling of the message side if
we went that route. I agree, no new lines. 

Anyone with any objections?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
Sent: February-24-09 10:57 AM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

I vote for strongly encouraging no new lines in the XML, and warning 
implementers that it might crap out if they include any. I HATE base64 
encoding and decoding messages!  Kind of defeats the purpose of using 
XML in the message in the first place...

BTW, I can confirm after scouring the Web for info that lots of programs 
(e.g. Microsoft IIS, IBM Websphere) have run into problems with 
multi-line headers, even in the last couple of years.

Edward Kawas wrote:
> You bring up a very good point. I think that we could either agree to use
no
> new lines. 
>
> Another, less desirable, option might be to base64 encode the header... I
> like your idea more though (I like sitting on the fence ...)
>
> Eddie 
>
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:43 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>
> According to RFC2616, which references RFC822 section 3.1, you can 
> indeed have multi-line header field value, as long as each extra line 
> starts with some linear white space.  Otherwise it'll think a new line 
> is a new header (and probably a malformed one at that).  There is a 
> standard for "folding" and "unfolding" such multi-line headers, which 
> essential strips CR and LF out of the message on the receiving end.  I'm 
> not sure how well this folding and unfolding protocol is handled by 
> various servers and clients, but given that new lines will be stripped 
> out on the receiving end anyway, should we say that the biomoby-wsrf 
> field XML value should have no new lines, for maximum likelihood of 
> transactional success?
>
> Edward Kawas wrote:
>   
>> Hi Paul,
>>
>> I was thinking of just treating that XML doc as a string and placing that
>>     
> as
>   
>> the value for the header with key biomoby-wsrf.
>>
>> Do you think that will work?
>>
>> Eddie
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:17 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> Hi Eddie,
>>
>> Pardon my ignorance, I was quickly perusing the document, but in the 
>> document where you break down sample XML such as "Response from 
>> destroying the resource", how exact do you put that XML block in the 
>> header?  I though HTTP headers are usually name=value...
>>
>> Edward Kawas wrote:
>>   
>>     
>>> Hello all,
>>>
>>> Attached is a draft proposal describing asynchronous post services in
>>>     
>>>       
>> moby.
>>   
>>     
>>> It is very similar to the RFC for moby-async services, except that it is
>>> HTTP POST and not SOAP based.
>>>
>>> Be harsh but nice!
>>>
>>> Eddie 
>>>   
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>     
>>>       
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
>>     
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>   
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev



From jmfernandez at cnio.es  Tue Feb 24 23:45:44 2009
From: jmfernandez at cnio.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 25 Feb 2009 00:45:44 +0100
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49a4503f.16538c0a.5fb0.0d70@mx.google.com>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>
	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>
Message-ID: <49A486A8.1020003@cnio.es>

Hi everybody,
	yes, I also agree about no multi-line headers, because they could bring many
compatibility issues, and some "clever" intermediate firewall or proxy could
misunderstand them.

	Jos? Mar?a

Edward Kawas wrote:
> Yeah, I just wanted to throw out the other option for consideration. Besides
> encoding/decoding overhead, there is also a doubling of the message side if
> we went that route. I agree, no new lines. 
> 
> Anyone with any objections?
> 
> Eddie
> 
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:57 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
> 
> I vote for strongly encouraging no new lines in the XML, and warning 
> implementers that it might crap out if they include any. I HATE base64 
> encoding and decoding messages!  Kind of defeats the purpose of using 
> XML in the message in the first place...
> 
> BTW, I can confirm after scouring the Web for info that lots of programs 
> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
> multi-line headers, even in the last couple of years.
> 
> Edward Kawas wrote:
>> You bring up a very good point. I think that we could either agree to use
> no
>> new lines. 
>>
>> Another, less desirable, option might be to base64 encode the header... I
>> like your idea more though (I like sitting on the fence ...)
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:43 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> According to RFC2616, which references RFC822 section 3.1, you can 
>> indeed have multi-line header field value, as long as each extra line 
>> starts with some linear white space.  Otherwise it'll think a new line 
>> is a new header (and probably a malformed one at that).  There is a 
>> standard for "folding" and "unfolding" such multi-line headers, which 
>> essential strips CR and LF out of the message on the receiving end.  I'm 
>> not sure how well this folding and unfolding protocol is handled by 
>> various servers and clients, but given that new lines will be stripped 
>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>> field XML value should have no new lines, for maximum likelihood of 
>> transactional success?
>>
>> Edward Kawas wrote:
>>   
>>> Hi Paul,
>>>
>>> I was thinking of just treating that XML doc as a string and placing that
>>>     
>> as
>>   
>>> the value for the header with key biomoby-wsrf.
>>>
>>> Do you think that will work?
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:17 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> Hi Eddie,
>>>
>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>> document where you break down sample XML such as "Response from 
>>> destroying the resource", how exact do you put that XML block in the 
>>> header?  I though HTTP headers are usually name=value...
>>>
>>> Edward Kawas wrote:
>>>   
>>>     
>>>> Hello all,
>>>>
>>>> Attached is a draft proposal describing asynchronous post services in
>>>>     
>>>>       
>>> moby.
>>>   
>>>     
>>>> It is very similar to the RFC for moby-async services, except that it is
>>>> HTTP POST and not SOAP based.
>>>>
>>>> Be harsh but nice!
>>>>
>>>> Eddie 
>>>>   
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>     
>>>>       
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>     
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 

-- 
"There is no reason why anybody would want a computer in their home" -
	Ken Olson, founder of DEC 1977
"640K ought to be enough for anybody" - Bill Gates, 1981
"Nobody will ever outgrow a 20Mb hard drive." - ???

"Premature optimization is the root of all evil." - Donald Knuth

Jos? Mar?a Fern?ndez Gonz?lez
Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 3061)
e-mail: jmfernandez at cnio.es		Fax: (+34) 91 224 69 76
Unidad del Instituto Nacional de Bioinform?tica
Biolog?a Estructural y Biocomputaci?n	Structural Biology and Biocomputing
Centro Nacional de Investigaciones Oncol?gicas
C.P.: 28029				Zip Code: 28029
C/. Melchor Fern?ndez Almagro, 3	Madrid (Spain)

**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies.



From edward.kawas at gmail.com  Fri Feb 27 21:22:42 2009
From: edward.kawas at gmail.com (Edward Kawas)
Date: Fri, 27 Feb 2009 13:22:42 -0800
Subject: [MOBY-dev] RFC for asynchronous POST services
In-Reply-To: <49A486A8.1020003@cnio.es>
References: <49a31d97.0e538c0a.1915.4402@mx.google.com>	<49A439A2.5080308@ucalgary.ca>	<49a43ad1.14b48c0a.79f7.ffffc42f@mx.google.com>	<49A43FC6.30303@ucalgary.ca>	<49a44158.14b48c0a.7a1d.1df9@mx.google.com>	<49A44301.9030802@ucalgary.ca>	<49a4503f.16538c0a.5fb0.0d70@mx.google.com>
	<49A486A8.1020003@cnio.es>
Message-ID: <49a859a8.02578c0a.07c7.ffff8edd@mx.google.com>

Another thing that I ran into today is that the HTTP header XML for polling,
requesting results, and destroying the job need a root element. What does
everyone think about wrapping the header as defined in the RFC with
<moby-wsrf></moby-wsrf>?

Eddie

-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Jos? Mar?a
Fern?ndez Gonz?lez
Sent: February-24-09 3:46 PM
To: Core developer announcements
Subject: Re: [MOBY-dev] RFC for asynchronous POST services

Hi everybody,
	yes, I also agree about no multi-line headers, because they could
bring many
compatibility issues, and some "clever" intermediate firewall or proxy could
misunderstand them.

	Jos? Mar?a

Edward Kawas wrote:
> Yeah, I just wanted to throw out the other option for consideration.
Besides
> encoding/decoding overhead, there is also a doubling of the message side
if
> we went that route. I agree, no new lines. 
> 
> Anyone with any objections?
> 
> Eddie
> 
> -----Original Message-----
> From: moby-dev-bounces at lists.open-bio.org
> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
> Sent: February-24-09 10:57 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
> 
> I vote for strongly encouraging no new lines in the XML, and warning 
> implementers that it might crap out if they include any. I HATE base64 
> encoding and decoding messages!  Kind of defeats the purpose of using 
> XML in the message in the first place...
> 
> BTW, I can confirm after scouring the Web for info that lots of programs 
> (e.g. Microsoft IIS, IBM Websphere) have run into problems with 
> multi-line headers, even in the last couple of years.
> 
> Edward Kawas wrote:
>> You bring up a very good point. I think that we could either agree to use
> no
>> new lines. 
>>
>> Another, less desirable, option might be to base64 encode the header... I
>> like your idea more though (I like sitting on the fence ...)
>>
>> Eddie 
>>
>> -----Original Message-----
>> From: moby-dev-bounces at lists.open-bio.org
>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>> Sent: February-24-09 10:43 AM
>> To: Core developer announcements
>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>
>> According to RFC2616, which references RFC822 section 3.1, you can 
>> indeed have multi-line header field value, as long as each extra line 
>> starts with some linear white space.  Otherwise it'll think a new line 
>> is a new header (and probably a malformed one at that).  There is a 
>> standard for "folding" and "unfolding" such multi-line headers, which 
>> essential strips CR and LF out of the message on the receiving end.  I'm 
>> not sure how well this folding and unfolding protocol is handled by 
>> various servers and clients, but given that new lines will be stripped 
>> out on the receiving end anyway, should we say that the biomoby-wsrf 
>> field XML value should have no new lines, for maximum likelihood of 
>> transactional success?
>>
>> Edward Kawas wrote:
>>   
>>> Hi Paul,
>>>
>>> I was thinking of just treating that XML doc as a string and placing
that
>>>     
>> as
>>   
>>> the value for the header with key biomoby-wsrf.
>>>
>>> Do you think that will work?
>>>
>>> Eddie
>>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at lists.open-bio.org
>>> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon
>>> Sent: February-24-09 10:17 AM
>>> To: Core developer announcements
>>> Subject: Re: [MOBY-dev] RFC for asynchronous POST services
>>>
>>> Hi Eddie,
>>>
>>> Pardon my ignorance, I was quickly perusing the document, but in the 
>>> document where you break down sample XML such as "Response from 
>>> destroying the resource", how exact do you put that XML block in the 
>>> header?  I though HTTP headers are usually name=value...
>>>
>>> Edward Kawas wrote:
>>>   
>>>     
>>>> Hello all,
>>>>
>>>> Attached is a draft proposal describing asynchronous post services in
>>>>     
>>>>       
>>> moby.
>>>   
>>>     
>>>> It is very similar to the RFC for moby-async services, except that it
is
>>>> HTTP POST and not SOAP based.
>>>>
>>>> Be harsh but nice!
>>>>
>>>> Eddie 
>>>>   
>>>>
------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>     
>>>>       
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>>
>>>   
>>>     
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>
>>   
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> 

-- 
"There is no reason why anybody would want a computer in their home" -
	Ken Olson, founder of DEC 1977
"640K ought to be enough for anybody" - Bill Gates, 1981
"Nobody will ever outgrow a 20Mb hard drive." - ???

"Premature optimization is the root of all evil." - Donald Knuth

Jos? Mar?a Fern?ndez Gonz?lez
Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 3061)
e-mail: jmfernandez at cnio.es		Fax: (+34) 91 224 69 76
Unidad del Instituto Nacional de Bioinform?tica
Biolog?a Estructural y Biocomputaci?n	Structural Biology and Biocomputing
Centro Nacional de Investigaciones Oncol?gicas
C.P.: 28029				Zip Code: 28029
C/. Melchor Fern?ndez Almagro, 3	Madrid (Spain)

**NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los
ficheros adjuntos, pueden contener informaci?n protegida para el uso
exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o
cualquier otro tipo de transmisi?n por parte de otra persona que no sea el
destinatario. Si usted recibe por error este correo, se ruega comunicarlo al
remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may
contain confidential and privileged information for the sole use of the
designated recipient named above. Distribution, reproduction or any other
use of this transmission by any party other than the intended recipient is
prohibited. If you are not the intended recipient please contact the sender
and delete all copies.

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev