From octave.noubibou at gsf.de Mon Mar 7 10:52:35 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Mon Mar 7 10:42:57 2005
Subject: [MOBY-dev] java api
In-Reply-To: <200502190736.j1J7aPKr002666@portal.open-bio.org>
References: <200502190736.j1J7aPKr002666@portal.open-bio.org>
Message-ID: <422C78C3.1020003@gsf.de>
Hi all,
as promised in my previous mail(see below), i have attached to this
message my source codes for parsing moby input xml .
The "RetrieveElementWS.java" class is just to show how you can use it.
your comments are welcome
octave
>
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>as Yan has mentioned, i have joined the PlaNet project at MIPS
>>>>since 3 months now. one of my first tasks was to provide a generic
>>>>API to simplify access to the pameters (queryID, namespace, id)
>>>>one needs from the moby input xml to run the services and also methods
>>>>to generate moby conform xml result.
>>>>
>>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>>purpose.
>>>>At the moment all you need to get your parameters is to use the method
>>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>>This method return a vector of the form e.g.:
>>>>
>>>>(((queryID1,ns,id))) for a simple type
>>>>
>>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>>collection
>>>>
>>>>or
>>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>>for an input with 2 invocations, the first been a collection and the
>>>>second a simple type.
>>>>
>>>>currently i do not handle secondary articles, but this should not be
>>>>difficult.
>>>>
>>>>we habe tried in our java services and everything seems to be ok.
>>>>
>>>>i am commenting the code now. once it is finished, i will like to
>>>>share it with you for comment or rectification and of course use.
>>>>Is there any possibility to upload this in central repository?
>>>>
>>>>best regards
>>>>
>>>>octave
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericInputParser.java
Type: text/x-java
Size: 11797 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/GenericInputParser-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetInputDataForQuery.java
Type: text/x-java
Size: 2581 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/GetInputDataForQuery-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericMobyOutputwriter.java
Type: text/x-java
Size: 14047 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/GenericMobyOutputwriter-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RetrieveElementWS.java
Type: text/x-java
Size: 6154 bytes
Desc: not available
Url : http://biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/RetrieveElementWS-0001.bin
From mwilkinson at mrl.ubc.ca Mon Mar 7 12:40:04 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon Mar 7 11:31:23 2005
Subject: [MOBY-dev] Registration for the May 7/8 BioMOBY meeting in Vancouver
Message-ID: <1110217204.3898.418.camel@mobycentral.icapture.ubc.ca>
Hi all,
I've set up a CGI form for registration. Please submit your
registration ASAP so that I can complete the budget for the meeting. I
will be doing my best to supplement your room and food from my grant so
that your travel will be the primary expense to you.
http://biomoby.org/cgi-bin/register.cgi
Cheers! See you all in Vancouver!
Mark
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Tue Mar 8 19:54:59 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue Mar 8 19:49:00 2005
Subject: [MOBY-dev] bug fix (??) for collection inputs/outputs
Message-ID: <1110329699.9567.11.camel@mobycentral.icapture.ubc.ca>
I've claimed that before on this bug, but it seems to be an unusually
pesky one! Anyway, the next attempt has just been committed.
I **think** that database entries for collection objects should now,
properly, write a service_instance_id of NULL into the database for
their simple_input/output tables. The problem has been that they have
been writing "0" and this causes them to not show up in the XML service
signature from a findService call.
If you are running your own MOBY Central you will need to update the
database by hand... again... sorry! I thought I had killed this one
months ago, but apparently not.
update simple_input set service_instance_id=NULL where
service_instance_id=0
(same for simple_output)
my apologies again!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Fri Mar 11 16:25:54 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Fri Mar 11 16:21:46 2005
Subject: [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
Message-ID: <42320CE2.3040201@cnb.uam.es>
Hi MOBYfiers!
I think I have found a bug in
MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
nodes. When getNodeContentWithArticle is handling nodes with its content
encapsulated in a CDATA section (for instance, a Blast result, a
sequence with a description, or an XML content), it ignores it. So, any
perl service which uses this function would not be able to get the
content when any MOBY client uses CDATA to maintain the original layout.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Fri Mar 11 17:15:05 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri Mar 11 17:08:47 2005
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <42320CE2.3040201@cnb.uam.es>
References: <42320CE2.3040201@cnb.uam.es>
Message-ID: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Committed a fix - try it now.
M
On Fri, 2005-03-11 at 13:25, José María Fernández González wrote:
> Hi MOBYfiers!
> I think I have found a bug in
> MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
> nodes. When getNodeContentWithArticle is handling nodes with its content
> encapsulated in a CDATA section (for instance, a Blast result, a
> sequence with a description, or an XML content), it ignores it. So, any
> perl service which uses this function would not be able to get the
> content when any MOBY client uses CDATA to maintain the original layout.
>
> Best Regards,
> José María
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Fri Mar 11 17:15:05 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri Mar 11 17:08:47 2005
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <42320CE2.3040201@cnb.uam.es>
References: <42320CE2.3040201@cnb.uam.es>
Message-ID: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Committed a fix - try it now.
M
On Fri, 2005-03-11 at 13:25, José María Fernández González wrote:
> Hi MOBYfiers!
> I think I have found a bug in
> MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
> nodes. When getNodeContentWithArticle is handling nodes with its content
> encapsulated in a CDATA section (for instance, a Blast result, a
> sequence with a description, or an XML content), it ignores it. So, any
> perl service which uses this function would not be able to get the
> content when any MOBY client uses CDATA to maintain the original layout.
>
> Best Regards,
> José María
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Mon Mar 14 10:41:13 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon Mar 14 10:37:07 2005
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
References: <42320CE2.3040201@cnb.uam.es>
<1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Message-ID: <4235B099.402@cnb.uam.es>
Yes, it works!
Thanks, Mark!!
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From jmfernandez at cnb.uam.es Mon Mar 14 10:54:30 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon Mar 14 10:50:09 2005
Subject: [MOBY-dev] About serviceNotes block
Message-ID: <4235B3B6.7090508@cnb.uam.es>
Hi again, MOBYfiers!
I am exploring the use of the serviceNotes block, and from the BioMOBY
v0.8 documents I have understood that only textual (human readable)
content should go inside it. Would it be a BioMOBY protocol violation if
I use it to send some XML content? I want to use it to communicate some
warnings related to services which answer a collection, and I want to
separate warnings from different answers (I don't want to go back to
flat file world!).
Also, I think I have found a possible bug in the current implementation
of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
getNodeContentWithArticle.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Mon Mar 14 13:55:30 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon Mar 14 15:26:25 2005
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235B3B6.7090508@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
Message-ID: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 07:54, José María Fernández González wrote:
> Also, I think I have found a possible bug in the current implementation
> of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
> getNodeContentWithArticle.
fixed. Let me know if it is still a problem.
> Would it be a BioMOBY protocol violation if
> I use it to send some XML content? I want to use it to communicate some
> warnings related to services which answer a collection, and I want to
> separate warnings from different answers (I don't want to go back to
> flat file world!).
to be honest, we haven't thought much about what should/not go into that
block. It was intentionally left ambiguous so that we could discuss it
at some point in the future. It appears that the point has now come!
My gut is that we should not just stick raw XML in there, since that
isn't very MOBYesque... the MOBYesque way would be to make another
ontology :-) A "commentary ontology" or something like that - then wrap
your XML according to its type.
what kinds of information do you have in your XML?
Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
provision information data? Do you have a defined set of predicates for
that?
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Mon Mar 14 13:55:30 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon Mar 14 15:26:28 2005
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235B3B6.7090508@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
Message-ID: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 07:54, José María Fernández González wrote:
> Also, I think I have found a possible bug in the current implementation
> of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
> getNodeContentWithArticle.
fixed. Let me know if it is still a problem.
> Would it be a BioMOBY protocol violation if
> I use it to send some XML content? I want to use it to communicate some
> warnings related to services which answer a collection, and I want to
> separate warnings from different answers (I don't want to go back to
> flat file world!).
to be honest, we haven't thought much about what should/not go into that
block. It was intentionally left ambiguous so that we could discuss it
at some point in the future. It appears that the point has now come!
My gut is that we should not just stick raw XML in there, since that
isn't very MOBYesque... the MOBYesque way would be to make another
ontology :-) A "commentary ontology" or something like that - then wrap
your XML according to its type.
what kinds of information do you have in your XML?
Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
provision information data? Do you have a defined set of predicates for
that?
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Mon Mar 14 16:03:38 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon Mar 14 15:59:17 2005
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
Message-ID: <4235FC2A.9030807@cnb.uam.es>
>
> fixed. Let me know if it is still a problem.
>
Okay, getServiceNotes works with CDATA.
> what kinds of information do you have in your XML?
>
Well, something like the next one. This is an example from INB
(http://www.inab.org) guys, which are stretching BioMOBY to its limits.
You should note they are using a different namespace, so they are
avoiding past, present and future XML tag collisions:
incomplete_outputIntAct DB engine was not
available
Looking at the example, the structure is describing that answer with
queryID 'b2' could be incomplete because some of the used databases was
not available at runtime. INB prefers serviceNotes block instead of
ProvisionInformation block because most of the warnings, and in general,
exception information, comprise the whole output, which is a Collection
for some services.
The other drawback for ProvisionInformation is that it cannot appear in
a mobyData outside any object, or even Simple or Collection
declarations, so it becomes useless when you want (or need) to notify
some information related to a Collection, or there is no answer at all
because there was a problem with that query.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Mon Mar 14 16:27:29 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon Mar 14 16:22:55 2005
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235FC2A.9030807@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
<4235FC2A.9030807@cnb.uam.es>
Message-ID: <1110835649.29060.127.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 13:03, José María Fernández González wrote:
> INB prefers serviceNotes block instead of
> ProvisionInformation block because most of the warnings, and in general,
> exception information, comprise the whole output, which is a Collection
> for some services.
That's an interesting observation - I hadn't thought about that. The
reason for the ProvisionInformation block being a part of an object was
so that different subcomponents of a complex object could potentially
have different provision annotations... however you rightly point out
that this would all have to be duplicated if these were part of a
collection, and that it would be more efficient to have it at that
level.
The serviceNotes block is the place where I had intended for this
"global" type of information to be placed - we just need to agree on a
format.
> The other drawback for ProvisionInformation is that it cannot appear in
> a mobyData outside any object, or even Simple or Collection
> declarations, so it becomes useless when you want (or need) to notify
> some information related to a Collection,
I like the provision information block where it is for the reasons I
indicate above, but I tend to agree with you that there is possibly a
need for one additional level of provider feedback (I have to point out,
however, that as far as I know you and I are the only people who are
using these extra parts of the MOBY message ;-) )
> or there is no answer at all
> because there was a problem with that query.
It was intended that a blank mobyData node would indicate a "problem",
but it is not possible to differentiate between a problematic query, and
the lack of an answer to a valid query at this level. Since the whole
MOBY thing is intended to be accessed by machines, we would have had to
build (or re-build) a large vocabulary of possible error messages in
order to create a machine-readable solution to errors at this level of
resolution... and since we cannot reasonably predict all of the possible
errors to the level of resolution required for a machine to fix the
problem on its own, this seemed a bit futile... so I didn't bother.
A blank mobyData block means "I don't know what you are talking about" -
for whatever reason; it may be, but it is not necessarily an error.
This is something we could re-visit at the next MOBY meeting, however.
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Tue Mar 15 19:09:37 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue Mar 15 19:02:29 2005
Subject: [MOBY-dev] REGISATRATION CALL #2 MOBY-DIC meeting
Message-ID: <1110931777.3201.18.camel@mobycentral.icapture.ubc.ca>
Hi all,
Just re-pinging everyone who wants to come to Vancouver for the MOBY DIC
meeting in May (7/8). PLEASE REGISTER AS SOON AS POSSIBLE at:
http://www.biomoby.org/cgi-bin/register.cgi
I am pretty sure now that I will be able to cover 100% of your housing
costs, and probably some of the meal costs as well. I'm still working
out the final budget, but I do need to know how many people are coming
before I can come up with the final number.
My current guesstimate is that the registration fees (to cover your room
for up to three nights, and breakfast + lunch on the two meeting days)
will be about CAD$200. I will try to bring that even lower if I can!
Cheers!
Mark
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Wed Mar 16 09:01:35 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed Mar 16 08:57:13 2005
Subject: [MOBY-dev] Some Perl warnings in registerService with secondaries
Message-ID: <42383C3F.9070102@cnb.uam.es>
Hi MOBYfiers!
after some tests with registerService and a service definition with
secondaries, I have realized that you have to declare an empty list of
enums in each secondary parameter, so the method registers your service.
Also, even when a secondary parameter does not have minimum, maximum or
default value, the method uses it internally, and so the warnings are
ocurring.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 946.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 948.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 949.
As I have seen inside the code, it seems registerService submits all
these fields to MOBY Central, even when they have not been declared.
But, it should not do it... Is it perhaps a bug?
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From markw at illuminae.com Wed Mar 16 10:42:42 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Mar 16 10:37:16 2005
Subject: [unclassified] [MOBY-dev] Some Perl warnings in registerService
with secondaries
In-Reply-To: <42383C3F.9070102@cnb.uam.es>
References: <42383C3F.9070102@cnb.uam.es>
Message-ID: <423853F2.2040307@illuminae.com>
Hi Jos?,
Thanks for the bug report! I'm glad someone else is using the secondary
parameter code - up to now, I think only our friends at the Pasteur
institute were using them, but the more eyes/fingers we have testing
these the better!
Could you please do a CVS update so that your error messages line up
with the current codebase? that will make it easier to debug. e.g. in
my copy of the code, line 948 is blank, so it should not be throwing the
error you indicate below.
I will continue exploring the problem until I hear back from you.
Cheers!
M
Jos? Mar?a Fern?ndez Gonz?lez wrote:
> Hi MOBYfiers!
> after some tests with registerService and a service definition
> with secondaries, I have realized that you have to declare an empty
> list of enums in each secondary parameter, so the method registers
> your service. Also, even when a secondary parameter does not have
> minimum, maximum or default value, the method uses it internally, and
> so the warnings are ocurring.
>
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 946.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 948.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 949.
>
> As I have seen inside the code, it seems registerService submits
> all these fields to MOBY Central, even when they have not been
> declared. But, it should not do it... Is it perhaps a bug?
>
> Best Regards,
> Jos? Mar?a
From jmfernandez at cnb.uam.es Wed Mar 16 11:15:22 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed Mar 16 11:11:27 2005
Subject: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <423853F2.2040307@illuminae.com>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
Message-ID: <42385B9A.9070803@cnb.uam.es>
Hi Mark,
I have made a cvs update -dP and my moby-live copy was already
up-to-date. I am using the default branch and server
(cvs@cvs.open-bio.org:/home/repository/moby). Are you talking about
another different branch/server?
Cheers,
Jos? Mar?a
Mark Wilkinson wrote:
> Hi Jos?,
>
> Thanks for the bug report! I'm glad someone else is using the secondary
> parameter code - up to now, I think only our friends at the Pasteur
> institute were using them, but the more eyes/fingers we have testing
> these the better!
>
> Could you please do a CVS update so that your error messages line up
> with the current codebase? that will make it easier to debug. e.g. in
> my copy of the code, line 948 is blank, so it should not be throwing the
> error you indicate below.
>
> I will continue exploring the problem until I hear back from you.
>
> Cheers!
>
> M
>
>
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Wed Mar 16 13:11:38 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 16 13:04:45 2005
Subject: [moby] Re: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <42385B9A.9070803@cnb.uam.es>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
<42385B9A.9070803@cnb.uam.es>
Message-ID: <1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
hmmmmm.... I think I am working on HEAD. I just did a fresh checkout
and I still get the lines you indicate as either blank or commented-out
in that copy as well.
??
Anyway, I will try to reproduce the problem first, and if I can
reproduce it, I'll debug it and commit the changes to HEAD. Then we
should see if you are able to update these into your version.
Cheers!
M
On Wed, 2005-03-16 at 08:15, José María Fernández González wrote:
> Hi Mark,
> I have made a cvs update -dP and my moby-live copy was already
> up-to-date. I am using the default branch and server
> (cvs@cvs.open-bio.org:/home/repository/moby). Are you talking about
> another different branch/server?
>
> Cheers,
> José María
>
> Mark Wilkinson wrote:
> > Hi José,
> >
> > Thanks for the bug report! I'm glad someone else is using the secondary
> > parameter code - up to now, I think only our friends at the Pasteur
> > institute were using them, but the more eyes/fingers we have testing
> > these the better!
> >
> > Could you please do a CVS update so that your error messages line up
> > with the current codebase? that will make it easier to debug. e.g. in
> > my copy of the code, line 948 is blank, so it should not be throwing the
> > error you indicate below.
> >
> > I will continue exploring the problem until I hear back from you.
> >
> > Cheers!
> >
> > M
> >
> >
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 13:18:13 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 16 13:10:27 2005
Subject: [moby] Re: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
<42385B9A.9070803@cnb.uam.es>
<1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110997093.6585.26.camel@mobycentral.icapture.ubc.ca>
D'OH!
Me being stupid (actually, my editor being stupid, but me not noticing)
We're working on the same code, and I can replicate your error.
Fixing it now...
M
On Wed, 2005-03-16 at 10:11, Mark Wilkinson wrote:
> hmmmmm.... I think I am working on HEAD. I just did a fresh checkout
> and I still get the lines you indicate as either blank or commented-out
> in that copy as well.
>
> ??
>
> Anyway, I will try to reproduce the problem first, and if I can
> reproduce it, I'll debug it and commit the changes to HEAD. Then we
> should see if you are able to update these into your version.
>
> Cheers!
>
> M
>
>
> On Wed, 2005-03-16 at 08:15, José María Fernández González wrote:
> > Hi Mark,
> > I have made a cvs update -dP and my moby-live copy was already
> > up-to-date. I am using the default branch and server
> > (cvs@cvs.open-bio.org:/home/repository/moby). Are you talking about
> > another different branch/server?
> >
> > Cheers,
> > José María
> >
> > Mark Wilkinson wrote:
> > > Hi José,
> > >
> > > Thanks for the bug report! I'm glad someone else is using the secondary
> > > parameter code - up to now, I think only our friends at the Pasteur
> > > institute were using them, but the more eyes/fingers we have testing
> > > these the better!
> > >
> > > Could you please do a CVS update so that your error messages line up
> > > with the current codebase? that will make it easier to debug. e.g. in
> > > my copy of the code, line 948 is blank, so it should not be throwing the
> > > error you indicate below.
> > >
> > > I will continue exploring the problem until I hear back from you.
> > >
> > > Cheers!
> > >
> > > M
> > >
> > >
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 14:02:44 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 16 13:54:49 2005
Subject: [MOBY-dev] My bad! database strucural change needed.
Message-ID: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
To everyone running a local MOBY Central:
We need to update the table structure for MOBY Central in light of the
bug fix for Jose's reported bug this morning. Sorry everyone!
mysql> alter table secondary_input modify datatype varchar(20);
It was not recording secondary datatypes properly. There was only one
instance of an incorrect record in the public registry database and I
was able to fix that one by hand. Hopefully it should be similarly
simple for everyone else.
I'm committing the code changes to the CVS right now.
what colour is MY red face?! :-)
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 14:05:01 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 16 13:57:07 2005
Subject: [MOBY-dev] NIX THAT was Re: My bad! database strucural change
needed.
In-Reply-To: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
References: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
NIX THAT LAST MESSAGE - it was the test instance of MOBY Central that
was defective, the production instance is correct.
...>>sigh<<.... bad day for debugging...
M
On Wed, 2005-03-16 at 11:02, Mark Wilkinson wrote:
> To everyone running a local MOBY Central:
>
> We need to update the table structure for MOBY Central in light of the
> bug fix for Jose's reported bug this morning. Sorry everyone!
>
> mysql> alter table secondary_input modify datatype varchar(20);
>
> It was not recording secondary datatypes properly. There was only one
> instance of an incorrect record in the public registry database and I
> was able to fix that one by hand. Hopefully it should be similarly
> simple for everyone else.
>
> I'm committing the code changes to the CVS right now.
>
> what colour is MY red face?! :-)
>
> M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 14:05:01 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 16 13:57:09 2005
Subject: [MOBY-dev] NIX THAT was Re: My bad! database strucural change
needed.
In-Reply-To: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
References: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
NIX THAT LAST MESSAGE - it was the test instance of MOBY Central that
was defective, the production instance is correct.
...>>sigh<<.... bad day for debugging...
M
On Wed, 2005-03-16 at 11:02, Mark Wilkinson wrote:
> To everyone running a local MOBY Central:
>
> We need to update the table structure for MOBY Central in light of the
> bug fix for Jose's reported bug this morning. Sorry everyone!
>
> mysql> alter table secondary_input modify datatype varchar(20);
>
> It was not recording secondary datatypes properly. There was only one
> instance of an incorrect record in the public registry database and I
> was able to fix that one by hand. Hopefully it should be similarly
> simple for everyone else.
>
> I'm committing the code changes to the CVS right now.
>
> what colour is MY red face?! :-)
>
> M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From edward.kawas at gmail.com Wed Mar 16 15:18:01 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed Mar 16 15:17:04 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Hi,
I was wondering if people could let me know what version of
Java people are using. I was hoping to see if we could
somehow push everyone towards using 1.5 in the near future.
I know the upgrade isn't trivial, so I was hoping to hear
your comments.
Thanks,
Eddie
From edward.kawas at gmail.com Wed Mar 16 15:18:01 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed Mar 16 15:19:37 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Hi,
I was wondering if people could let me know what version of
Java people are using. I was hoping to see if we could
somehow push everyone towards using 1.5 in the near future.
I know the upgrade isn't trivial, so I was hoping to hear
your comments.
Thanks,
Eddie
From bmg at sfu.ca Wed Mar 16 15:48:20 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed Mar 16 15:48:08 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <42389B94.3070106@sfu.ca>
Happy to move on to 1.5, would be helpful for some of the things I'm doing.
-Ben
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
From gordonp at ucalgary.ca Wed Mar 16 16:11:33 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed Mar 16 16:06:03 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389B94.3070106@sfu.ca>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
<42389B94.3070106@sfu.ca>
Message-ID: <4238A105.2050701@ucalgary.ca>
I haven't played around with 1.5 much yet, as I haven't needed its new
features (I'm using 1.4.2). I think that if the existing MOBY code
works fine in 1.5, we should move forward and let people use Generics,
etc. in the codebase. Better to do this transition before even more
people are developing code...
Benjamin Good wrote:
> Happy to move on to 1.5, would be helpful for some of the things I'm
> doing.
>
> -Ben
>
> Eddie Kawas wrote:
>
>> Hi,
>>
>> I was wondering if people could let me know what version of
>> Java people are using. I was hoping to see if we could
>> somehow push everyone towards using 1.5 in the near future.
>> I know the upgrade isn't trivial, so I was hoping to hear
>> your comments.
>>
>> Thanks,
>>
>> Eddie
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev@biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
From ywong at infobiogen.fr Thu Mar 17 04:03:41 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Thu Mar 17 03:58:08 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <423947ED.9090103@infobiogen.fr>
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
java 1.4.2 and java 1.5
From octave.noubibou at gsf.de Thu Mar 17 05:12:44 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Thu Mar 17 05:04:16 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <4239581C.9030909@gsf.de>
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
hi Eddie,
currently, we are using 1.4.2. i hoppe it should not be a big problem to
move to 1.5 if needed.
octave
From tmo at ebi.ac.uk Thu Mar 17 08:13:48 2005
From: tmo at ebi.ac.uk (Tom Oinn)
Date: Thu Mar 17 08:09:55 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <4239581C.9030909@gsf.de>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
<4239581C.9030909@gsf.de>
Message-ID: <4239828C.2070602@ebi.ac.uk>
Octave Noubibou wrote:
> Eddie Kawas wrote:
>
>> Hi,
>>
>> I was wondering if people could let me know what version of
>> Java people are using. I was hoping to see if we could
>> somehow push everyone towards using 1.5 in the near future.
>> I know the upgrade isn't trivial, so I was hoping to hear
>> your comments.
Highly non trivial, are you using Axis? We've pretty much given up on
1.5 until the axis devs get their act together as right now it won't
work. We're using 1.4.2_07 for Taverna
Cheers,
Tom
From senger at ebi.ac.uk Mon Mar 21 09:44:31 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon Mar 21 09:38:55 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID:
> I was wondering if people could let me know what version of
> Java people are using. I was hoping to see if we could
> somehow push everyone towards using 1.5 in the near future.
>
There will never be a single date when people can stop using the old
version and start to use the new version. Therefore, there should be
some "transitional rules" to follow. The rules must be both for
the compilation and run-time. Here is how it perhaps can work:
a) The run-time is completely up to the code developer. If [s]he
insists (needs) to use newer Java 1.5 his/her code should be written in a
way that it throws an exception if run under older JVM.
b) The compilation time can be solved by having Java version checks in
Ant. Ant is prepared for it, and I can make it into jMoby build.xml. So if
you have a code, that you wish to commit to jMoby and this code requires
1.5. please send it first to me and I will make the changes in build.xml.
b1) There may be other targets in Ant (other than compilation) that
depend on Java version - such as deploying web services under Axis (as
pointed out Tom). I can also help with version checking for such targets
if you let me know (at the moment there is no such target in build.xml).
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From edward.kawas at gmail.com Mon Mar 21 12:01:44 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Mon Mar 21 11:56:01 2005
Subject: [MOBY-dev] Java packages conversation
Message-ID: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Hi,
Martin & I thought that our conversation might interest
others in the list, so here it is:
------------Eddie-------------------
Hi,
I have been trying to think of a package hierarchy that
would be useful for jMoby now and in the future. I have come
up with the following draft, and was hoping for criticism.
Below you will find the package structure I think might
work:
#######################
org.biomoby.central.
registry.
retrieval.
_to_be_named_later.
register
deregister
client.
perlConverts.
execution.
invocation
ui.
commandline.
graphical.
swing
applets
servlets.
lsid
jResource
plugins.
taverna
dom.
testing.
###########################
Anything that you think is missing? I hope to be able to
slot the current classes into these packages a little at a
time.
In the package perlConverts I was hoping to slot in java
versions of Perl scripts that have been already created,
like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
cgi-bin/types/Namespaces.
In the package dom, I thought that people may be comfortable
with a particular version of dom (w3c.dom, jDom, etc) and so
I thought it might be nice to separate implementations.
I think that the rest of the hierarchy is pretty straight
forward and doesn't need explanation, although I could be
wrong.
Also, I do not have as much knowledge about Moby as many of
you do and I may have missed some obvious things, so please
let me know.
Thanks,
Eddie Kawas
------------Martin----------------
Thanks for the overview.
I have just a few questions:
1) Does the new proposal require changes in the current
(existing) packages? If yes, in which?
2) Are you going to create package 'slots' now - and only
later to populate them, or are you proposing to create them
only when you have something to be there?
3) perlConverts: I do not feel comfortable with this
name. Do users need to know (from the package name) the
reason why a package was created?
I think that better is to name a package by its
functionality, not by the origin. But again, I would perhaps
let people to create their package names in a less
structured (less detailed) way than you are proposing (which
I will explain when I have answers for the two previous
questions)
- so if somebody wants to keep te origin in the package
name, I am not basically against it. Let's return to these
comments later.
4)
> In the package dom, I thought that people may be
comfortable with a
> particular version of dom (w3c.dom, jDom, etc) and so I
thought it
> might be nice to separate implementations.
>
Again, I think that this details should be (if one wants
to have several separate implementations) *below* package
where a dom is used. You ut it under 'client' - but what if
I need to use a dom in a class belonging to a registry
package, or to a commandLine package? The 'dom'
name should be there - in more than one place.
> I think that the rest of the hierarchy is pretty straight
forward and
> doesn't need explanation, although I could be wrong.
>
5)
Well, if you publish rules you need to explain them
anyway. So why not to do it now :-) It would be good to have
few lines defineg what should go into individual packages.
Cheers,
Martin
-------------Eddie--------------
> 1) Does the new proposal require changes in the current
> (existing)
> packages? If yes, in which?
Yes, however, I am not sure which classes will be moved
where. I tried to see what classes we had and then I tried
to create a slot that it might fit into.
> 2) Are you going to create package 'slots' now - and
only later to
> populate them, or are you proposing to create them only
when you have
> something to be there?
I was thinking of creating them now. Is this a bad idea?
> 3) perlConverts: I do not feel comfortable with this
name.
I agree. I think I did that out of sheer laziness.
> 4)
> > In the package dom ...
You are right, this should be below a package when DOM is
used, not in client.
Thanks,
Eddie
------------Martin----------------
> > 1) Does the new proposal require changes in the
current
> > (existing)
> > packages? If yes, in which?
> Yes, however, I am not sure which classes will be moved
where.
>
Well, I am reluctant to make these changes - at least in
the code written (mainly) by me - unless there is a good
reason for that. Changes in package names (in existing code)
are evil - if the code is already used by others. Sorry for
that...
> > 2) Are you going to create package 'slots' now - and
only later
> > to populate them, or are you proposing to create them
only when you
> > have something to be there?
> I was thinking of creating them now. Is this a bad idea?
>
I always liked such idea - but (in my experiences) it
simply never worked (unless you are in a strict industrial
environment). Therefore, I suggest to live with a compromise
- to "dictate" only relatively high-level package names, and
let people to create their own below.
Therefore, I have started only with
org.biomoby.[client|shared|registry] - and we need possibly
something for support for service providers (I am using now
org.biomoby.service - but there are only some testing
classes now).
Having said that, I think it is a good idea to write a
document - and to publish it on the jMoby pages - that would
suggest what package names (below the ones I mentioned
above) could be used for specific purposes.
But not to create them in advance, and not to enforce it
later. Just like hints. As always with hints, people will
follow them if the hints are well explained and known to
people.
Let me know if you are uncomfortable with the high-level
package names as they exist now - and let's discuss what to
do with them. BTW, your
proposal:
org.biomoby.central.
registry.
retrieval.
_to_be_named_later.
register
deregister
cannot work easily. Simply because it is too detailed. There
may be classes (such as CentralImpl) that work cross the
packages you defined.
No, I would definitely keep this part simpler - just
org.biomoby.registry.
(But this was just an example, let's discuss it.)
Cheers,
Martin
--------------Eddie---------------
So you don't think that we should try and create a more
detailed hierarchy. I thought that one would be nice,
because we were stumbling upon users that had created almost
duplicate code to that which was in jMoby. Ultimately, I was
hoping to reduce code duplication in order to get people
more on their way to doing useful things.
I realize that changing package names is going to be messy,
so we were proposing to do it slowly, maybe a package at a
time with advance warnings. We could have even tried
automating it with scripts that contain the mappings of
where current classes are and where they would be after the
'refactor'-ing.
What do you think?
Eddie
PS: I am all for creating a document that outlines what
should be placed where, etc.
------------Martin----------------
> I thought that one would be nice, because we were
stumbling upon users
> that had created almost duplicate code to that which was
in jMoby.
>
This is obviously bad and we should perhaps contact these
people and try to convince them to re-use existing code (I
am working now, for example, with Sophie Durand
to convince her to re-use some
exiting code for her classes). But I believe that changing
package names will not help to achieve it. We need different
ways to convince them.
> We could have even tried automating it with scripts that
contain the
> mappings of where current classes are and where they would
be after
> the 'refactor'-ing.
>
I agree that it would be useful to provide a refactoring
tool - if we need to refactor. But, as I said, I do not
think that refactoring will help us now.
Sorry for not agreeing with you on the package name
changes. But I still believe that providing hints how to
name their code would be very helpful.
Martin
PS. Btw, feel free to reproduce our conversation on the
biomoby-dev list if you wish. M.
--
Martin Senger
-----------Eddie-------------
Thanks for your comments, I think that I should rethink this
whole issue and then get back to you.
Eddie
From edward.kawas at gmail.com Mon Mar 21 12:14:34 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Mon Mar 21 12:09:37 2005
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To:
Message-ID: <423f00fb.14d19c85.67e0.0ec1@mx.gmail.com>
Martin,
May I ask you what it was you thought would be placed in the
packages client, shared, and registry when you created them?
Thanks,
Eddie
> -----Original Message-----
> From: moby-dev-bounces@portal.open-bio.org [mailto:moby-
> dev-bounces@portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Monday, March 21, 2005 6:45 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] What versions of JAVA is everyone
> using?
>
> > I was wondering if people could let me know what version
> of
> > Java people are using. I was hoping to see if we could
> > somehow push everyone towards using 1.5 in the near
> future.
> >
> There will never be a single date when people can stop
> using the old
> version and start to use the new version. Therefore, there
> should be
> some "transitional rules" to follow. The rules must be
> both for
> the compilation and run-time. Here is how it perhaps can
> work:
>
> a) The run-time is completely up to the code developer.
> If [s]he
> insists (needs) to use newer Java 1.5 his/her code should
> be written in a
> way that it throws an exception if run under older JVM.
>
> b) The compilation time can be solved by having Java
> version checks in
> Ant. Ant is prepared for it, and I can make it into jMoby
> build.xml. So if
> you have a code, that you wish to commit to jMoby and this
> code requires
> 1.5. please send it first to me and I will make the
> changes in build.xml.
>
> b1) There may be other targets in Ant (other than
> compilation) that
> depend on Java version - such as deploying web services
> under Axis (as
> pointed out Tom). I can also help with version checking
> for such targets
> if you let me know (at the moment there is no such target
> in build.xml).
>
> Cheers,
> Martin
>
> --
> Martin Senger
>
> EMBL Outstation - Hinxton Senger@EBI.ac.uk
> European Bioinformatics Institute Phone: (+44) 1223
> 494636
> Wellcome Trust Genome Campus (Switchboard:
> 494444)
> Hinxton Fax : (+44) 1223
> 494468
> Cambridge CB10 1SD
> United Kingdom
> http://industry.ebi.ac.uk/~senger
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
From gordonp at ucalgary.ca Mon Mar 21 12:35:10 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon Mar 21 12:29:30 2005
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
References: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Message-ID: <423F05CE.1060801@ucalgary.ca>
Hi Eddie,
A couple of thoughts:
-What about the data templates and instances? Is org.biomoby.shared
going away? Should there be a org.biomoby.data instead?
-Where should server side or combines server/client objects (e.g.
MobyRequest) go?
>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
> client.
> perlConverts.
> execution.
> invocation
> ui.
> commandline.
> graphical.
> swing
> applets
> servlets.
> lsid
> jResource
> plugins.
> taverna
> dom.
> testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong.
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
> Thanks for the overview.
> I have just a few questions:
>
> 1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
> 2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
> 3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
> 4)
>
>
>>In the package dom, I thought that people may be
>>
>>
>comfortable with a
>
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>
>>
>thought it
>
>
>>might be nice to separate implementations.
>>
>>
>>
> Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom'
>name should be there - in more than one place.
>
>
>
>>I think that the rest of the hierarchy is pretty straight
>>
>>
>forward and
>
>
>>doesn't need explanation, although I could be wrong.
>>
>>
>>
> 5)
> Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
> Cheers,
> Martin
>
>-------------Eddie--------------
>
>
>
>> 1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>
>
>> 2) Are you going to create package 'slots' now - and
>>
>>
>only later to
>
>
>>populate them, or are you proposing to create them only
>>
>>
>when you have
>
>
>>something to be there?
>>
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>
>
>> 3) perlConverts: I do not feel comfortable with this
>>
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>
>
>> 4)
>>
>>
>>>In the package dom ...
>>>
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>
>
>>> 1) Does the new proposal require changes in the
>>>
>>>
>current
>
>
>>>(existing)
>>>packages? If yes, in which?
>>>
>>>
>>Yes, however, I am not sure which classes will be moved
>>
>>
>where.
>
>
> Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>
>
>>> 2) Are you going to create package 'slots' now - and
>>>
>>>
>only later
>
>
>>>to populate them, or are you proposing to create them
>>>
>>>
>only when you
>
>
>>>have something to be there?
>>>
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>
>>
> I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
> Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
> Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined.
>No, I would definitely keep this part simpler - just
>org.biomoby.registry.
>(But this was just an example, let's discuss it.)
>
> Cheers,
> Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>
>
>>I thought that one would be nice, because we were
>>
>>
>stumbling upon users
>
>
>>that had created almost duplicate code to that which was
>>
>>
>in jMoby.
>
>
> This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>
>
>>We could have even tried automating it with scripts that
>>
>>
>contain the
>
>
>>mappings of where current classes are and where they would
>>
>>
>be after
>
>
>>the 'refactor'-ing.
>>
>>
>>
> I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
>
> Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
> Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
From ywong at infobiogen.fr Tue Mar 22 03:46:10 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Tue Mar 22 03:40:35 2005
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
References: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Message-ID: <423FDB52.1000603@infobiogen.fr>
Eddie Kawas wrote:
>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
> client.
> perlConverts.
> execution.
> invocation
> ui.
> commandline.
> graphical.
> swing
> applets
> servlets.
> lsid
> jResource
> plugins.
> taverna
> dom.
> testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong.
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
> Thanks for the overview.
> I have just a few questions:
>
> 1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
> 2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
> 3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
> 4)
>
>
>>In the package dom, I thought that people may be
>>
>>
>comfortable with a
>
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>
>>
>thought it
>
>
>>might be nice to separate implementations.
>>
>>
>>
> Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom'
>name should be there - in more than one place.
>
>
>
>>I think that the rest of the hierarchy is pretty straight
>>
>>
>forward and
>
>
>>doesn't need explanation, although I could be wrong.
>>
>>
>>
> 5)
> Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
> Cheers,
> Martin
>
>-------------Eddie--------------
>
>
>
>> 1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>
>
>> 2) Are you going to create package 'slots' now - and
>>
>>
>only later to
>
>
>>populate them, or are you proposing to create them only
>>
>>
>when you have
>
>
>>something to be there?
>>
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>
>
>> 3) perlConverts: I do not feel comfortable with this
>>
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>
>
>> 4)
>>
>>
>>>In the package dom ...
>>>
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>
>
>>> 1) Does the new proposal require changes in the
>>>
>>>
>current
>
>
>>>(existing)
>>>packages? If yes, in which?
>>>
>>>
>>Yes, however, I am not sure which classes will be moved
>>
>>
>where.
>
>
> Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>
>
>>> 2) Are you going to create package 'slots' now - and
>>>
>>>
>only later
>
>
>>>to populate them, or are you proposing to create them
>>>
>>>
>only when you
>
>
>>>have something to be there?
>>>
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>
>>
> I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
> Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
> Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined.
>No, I would definitely keep this part simpler - just
>org.biomoby.registry.
>(But this was just an example, let's discuss it.)
>
> Cheers,
> Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>
>
>>I thought that one would be nice, because we were
>>
>>
>stumbling upon users
>
>
>>that had created almost duplicate code to that which was
>>
>>
>in jMoby.
>
>
> This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>
>
>>We could have even tried automating it with scripts that
>>
>>
>contain the
>
>
>>mappings of where current classes are and where they would
>>
>>
>be after
>
>
>>the 'refactor'-ing.
>>
>>
>>
> I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
>
> Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
> Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev@biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
How about some ant tasks that would make registration to the central
possible in a build file?
From senger at ebi.ac.uk Tue Mar 22 04:23:53 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Mar 22 04:19:04 2005
Subject: Ant tasks (was: [MOBY-dev] Java packages conversation)
In-Reply-To: <423FDB52.1000603@infobiogen.fr>
Message-ID:
> How about some ant tasks that would make registration to the central
> possible in a build file?
>
It is surely possible, but Ant is not helpful too much in this case -
at least I think:
The registration can be achieved by calling MobyCmdLineClient - and
this can be done perfectly from Ant (Ant task can easily set CLASSPATH and
call a Java application - MobyCmdLineClient is a Java application, of
course). The problem starts with the parameters for this application (and
there may be really *many* parameters for the registration). I have not
find a way how to pass to an Ant target parameters from the Ant's
command-line (let me know please if anybody knows how to do it).
Therefore, you have to expressed all parameters as Java properties, let
Ant to put them in a file and then feed an application (it can be again a
slightly modified MobyCmdLineClient, here is no problem) from this file.
So you have to do a lot of writing (setting properties) before you invoke
Ant - perhaps the same amount but I guess even more than writing a short
script where you can put all your registration parameters directly.
That's why I think that Ant is not too helpful for making registration.
But if people think that it should be there I can make such Ant target.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From ywong at infobiogen.fr Tue Mar 22 05:30:05 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Tue Mar 22 05:24:23 2005
Subject: [MOBY-dev] Re: Ant tasks
In-Reply-To:
References:
Message-ID: <423FF3AD.2030000@infobiogen.fr>
Martin Senger wrote:
>>How about some ant tasks that would make registration to the central
>>possible in a build file?
>>
>>
>>
> It is surely possible, but Ant is not helpful too much in this case -
>at least I think:
> The registration can be achieved by calling MobyCmdLineClient - and
>this can be done perfectly from Ant (Ant task can easily set CLASSPATH and
>call a Java application - MobyCmdLineClient is a Java application, of
>course). The problem starts with the parameters for this application (and
>there may be really *many* parameters for the registration). I have not
>find a way how to pass to an Ant target parameters from the Ant's
>command-line (let me know please if anybody knows how to do it).
>Therefore, you have to expressed all parameters as Java properties, let
>Ant to put them in a file and then feed an application (it can be again a
>slightly modified MobyCmdLineClient, here is no problem) from this file.
>So you have to do a lot of writing (setting properties) before you invoke
>Ant - perhaps the same amount but I guess even more than writing a short
>script where you can put all your registration parameters directly.
> That's why I think that Ant is not too helpful for making registration.
>But if people think that it should be there I can make such Ant target.
>
> Cheers,
> Martin
>
>
>
I thought it was possible to add registration tasks as bioMoby
registration requests are XML.
Something like could exit in an ant build file:
Maybe we do not need to fully translate a request in an ant like syntax
but make the ant task understand the moby request
An ant task would look like this:
mobyPhytoprotGetByAGICodeRetrievalgenoplante-info.infobiogen.frhttp://genoplante-info.infobiogen.fr/webservices/phytoprot-planet.pygpsupport@infobiogen.fr0Access to Phytoprot's clusters, by accession
numberObjectAGI_LocusCodeStringAvsAAvsAAvsP
It would use the existant bioMoby XML syntax to describes tasks/parameters.
Regards
Yan
From senger at ebi.ac.uk Tue Mar 22 06:05:53 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Mar 22 06:00:05 2005
Subject: [MOBY-dev] Java packages conversation (was: What versions of
JAVA is everyone using?)
In-Reply-To: <423f00fb.14d19c85.67e0.0ec1@mx.gmail.com>
Message-ID:
> May I ask you what it was you thought would be placed in the
> packages client, shared, and registry when you created them?
>
Sure. (I am quoting partly from the jMoby API documentation. And I am
going to put these more detailed answers back there.)
Just a note (repeating what was already said in this thread): these are
meant to be high-level package names - and everybody is welcome to make
more specialized packages *within* (below) these packages. However, please
be aware that making a directory under CVS is a *big* change which is hard
to redo - so think twice before you commit a new directory.
'org.biomoby.clients' contains components used to develop Moby clients.
The Moby clients can be both clients of the Moby registry and clients of
the Moby services. It can also contain not only components but full
clients (even though I have put my full command-line client
MobyCmdLineClient elsewhere because of some obscure reasons I have not
put that client into any package).
'org.biomoby.registry' contains components helping with Moby registry.
These components are supposed to be used by those who are running a
registry. At the moment, there is not many components here, because most
of the registry implementation is in Perl. Note that if you write code
that *uses* registry by calling its API methods you should put it into the
'org.biomoby.client' package because in fact you are the clients of the
registry. Here should go components that use direct access to the registry
databases (like a direct JDBC access), or here we may have
Java-implementation of the whole registry soemday.
'org.biomoby.service' (which should be called actually better
'org.biomoby.services' - my fault) contains general components that can be
used by those writing code for moby services. This is not meant to be used
for the service-specific code - such some business logic to get to a plant
database at MIPS (for that I assume the developer will have his/her own
package name which is not committed to the jMoby CVS) - but for general
components that can be re-used by any/many service providers for their
services. Also here can go some example services that can be used as
templates for service providers.
And finally 'org.biomoby.shared' contains components that are used by
classes from more than one package above. The bottom-line (or a
bottom-rule) is: If one wants to run clients, it must be sufficent for him
to pack all classes from 'org.biomoby.client' *and* 'org.biomoby.shared'
only. If one wants to create a registry oriented component, it is enough
for him to pack 'org.biomoby.registry' *and* 'org.biomoby.shared'. And
similarly for service providers which would pack ''org.biomoby.service'
*and* 'org.biomoby.shared'.
Additionally the 'org.biomoby.shared' package is a good place for
putting there Java interfaces - assuming that they are expected to use
more generally. So I have put here Central.java - an interface defining an
access to a Moby registry - because I felt (and I still feel) that there
may be a component (using this interface) in other package than in
'org.biomoby.client'.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Tue Mar 22 06:40:03 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Mar 22 06:35:10 2005
Subject: [MOBY-dev] Re: Ant tasks
In-Reply-To: <423FF3AD.2030000@infobiogen.fr>
Message-ID:
> Something like could exit in an ant build file:
>
Thanks for your example. I apologize but I strongly oppose it. And I am
sorry that I perhaps have not expressed things clearly. There are two
arguments why your example should not be put, as it was suggested, into
Ant's build.xml (and I am talking about the build.xml distributed in jMoby
CVS; if you talk about your own build.xml somewhere in your local copy of
jMoby, your example is perfectly fine):
1) The build.xml is a general file that is used by anybody building
jMoby and using jMoby. So it cannot have specific things dealing with a
particular service, such as
PhytoprotGetByAGICode. One *can* have such
things in an Ant's build.xml if it is defined as a property - and one is
free to define his/her own properties either on Ant command line, or in a
local build.properties file. So your example would be something like:
${service.name}
and you have to put into your build.properties file a line:
service.name = PhytoprotGetByAGICode
or you would invoke jMoby Ant by typing:
./build-dev.sh -Dservice.name=PhytoprotGetByAGICode register
But considering how many properties one needs to set, it would be a lot of
writing - that's what I was talkeing about in my previous mail.
2) This is not a strong argument - and there may be other opinions on
that - but I feel like this: In jMoby (and AFAIK it is the same within the
perl moby libraries), you are encouraged not to use directly XML requested
by Moby registry but rather to use an API to access such registry. In
jMoby case it is a Java API defined in Central.java. Using this, you are
shared by potential changes in the native (XML-based) Moby API. Therefore,
I would not recommed to register your services by defining XML at all (not
only as a part of an Ant's build.xml).
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Tue Mar 22 07:12:17 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue Mar 22 07:09:01 2005
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423F05CE.1060801@ucalgary.ca>
Message-ID:
> -What about the data templates and instances?
>
What are data templates and instances?
> Is org.biomoby.shared going away? Should there be a org.biomoby.data
> instead?
>
I hope I have explained things in my previous email.
'org.biomoby.shared' will stay (as far as I can tell). If you feel a need
for a sub-package containing data structure feel free to create
'org.biomoby.shared.data' (but at the moment I am not going to move there
any of my data classes - simple, as explained earlier, it is too many
changes in the users code which is not justified now - I believe).
> -Where should server side or combines server/client objects (e.g.
> MobyRequest) go?
>
Why do you think that MobyRequest is a server/client combination? Do
you mean perhaps service/client combination? If that is the case, I think
this class should be in 'org.biomoby.shared' (or it its subpackage of your
choice). If this class is used only by clients (when they call a moby
service) then it should go to 'org.biomoby.client'.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From gss at ncgr.org Tue Mar 22 13:46:09 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue Mar 22 13:40:21 2005
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424067F1.10603@ncgr.org>
Not at the moment, but it does seem important to have a place to return
error messages. It is particularly important in a distributed
environment, since there are so many things that can go wrong
(transmission errors, servers being down, ...).
// Gary
Mark Wilkinson wrote:
>Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
>provision information data? Do you have a defined set of predicates for
>that?
>
From senger at ebi.ac.uk Wed Mar 23 10:24:12 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Mar 23 10:18:48 2005
Subject: [MOBY-dev] problems with Moby central
In-Reply-To: <1110906365.2107.18.camel@mobycentral.icapture.ubc.ca>
Message-ID:
Mark,
It seems that the Moby Central is broken at the moment. It cannot even
return a list of services. Instead it reports about an XML parse
exception. Would you mind to look at it please?
Many thanks,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From mwilkinson at mrl.ubc.ca Wed Mar 23 11:05:45 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 23 10:58:17 2005
Subject: [MOBY-dev] mobycentral revived
Message-ID: <1111593945.22484.18.camel@mobycentral.icapture.ubc.ca>
Hi all,
sorry about that - I was in post-surgery with my cat when it went down
and I never got back on-line until this AM.
MOBY Central is a bit flaky at the moment, and we can't figure out why.
It is a rather sudden flakyness that doesn't seem to correspond to any
particular change we have made. The Apache error logs fill up with
segfaults within a couple of hours and that crashes the system as the
amount of available memory goes to zero. MySQL seems to be having a
similar problem (it was mysql that had crashed last night). This all
seems to point to a physical memory error, but we can't detect one...
It may be time to get a new machine for MOBY :-)
Anyway, I'll keep an eye on it throughout the day. I have turned
apache's error logging to "critical" to reduce teh number of error
messages, so hopefully we'll have longer availability between crashes.
Sorry about this!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 23 11:53:44 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 23 11:44:26 2005
Subject: [MOBY-dev] recompiling Apache
Message-ID: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Hi everyone,
I've just found a posting that suggests that there is a conflict between
expat and apache. Expat is the XML parser that I believe is part of
libxml2 which is what is used by XML::LibXML - the new libraries that
are doing the XML parsing for MOBY Central.
I will need to recompile Apache to fix this problem (if it is the
problem...), so you might notice mobycentral going up and down over the
next 48 hours as I play with it, but I will try to limit my testing to
the test instance of the server so that it doesn't disturb anyone too
badly.
Sorry for the flakyness!
M
(this doesn't explain the crash of mysql... but it might just have been
a coincidence...)
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 23 15:43:07 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 23 15:34:08 2005
Subject: [MOBY-dev] Cut-off for MOBY-DIC registration: March 31, 2005.
Message-ID: <1111610587.24448.12.camel@mobycentral.icapture.ubc.ca>
Hi all,
Particularly pinging the S-MOBY crew, the CSHL crew, the Brisbane crew,
and anyone from myGrid or GO who wants to spend a few days away from the
dull Manchester/Hinxton rain lapping up the sun in Lotus Land :-) If
you have not registered yet, go to:
http://biomoby.org/cgi-bin/register.cgi
In order to make a budget and book the catering I have to set a cut-off
date for the MOBY DIC meeting registration. March 31st will be the last
date for attendees who want to take advantage of the substantially
discounted registration supplement from my Genome Canada grant, after
which you will be responsible for paying your own room and board.
So... if you haven't already registered... get on y'r horse! :-)
If you aren't sure if you have registered, go to
http://biomoby.org/regisrations.txt
I will make the final budget on the 1st of April and then will be able
to let you know exactly what the registration fees will be (including 3
nights and breakfast/lunch and coffee breaks for the the meeting days).
I'm still expecting this to be under $200, probably well under that
number.
Cheers all!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From senger at ebi.ac.uk Wed Mar 23 19:09:24 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Mar 23 19:05:27 2005
Subject: [MOBY-dev] recompiling Apache
In-Reply-To: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Message-ID:
> I've just found a posting that suggests that there is a conflict between
> expat and apache. Expat is the XML parser that I believe is part of
> libxml2
>
FYI, I do not know about libxml12 but I know that Expat is a base part
for XML::Parser.
I wish you luck with finding the cause of problems.
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Wed Mar 23 19:09:24 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed Mar 23 19:05:54 2005
Subject: [MOBY-dev] recompiling Apache
In-Reply-To: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Message-ID:
> I've just found a posting that suggests that there is a conflict between
> expat and apache. Expat is the XML parser that I believe is part of
> libxml2
>
FYI, I do not know about libxml12 but I know that Expat is a base part
for XML::Parser.
I wish you luck with finding the cause of problems.
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger@EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From markw at illuminae.com Wed Mar 23 21:40:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Mar 23 21:34:53 2005
Subject: [MOBY-dev] recompiling Apache
In-Reply-To:
References:
Message-ID: <424228A8.5040507@illuminae.com>
It seems to have settled down a bit now. All I did was install a newer
version of DBI!
There's still a segfault in the error log that happened some time in the
past 6 hours, but that is better than the several dozen per hour that
were happening a few days ago :-)
I'll keep an eye on it, but for now it seems somewhat stable (touch wood!)
M
Martin Senger wrote:
>>I've just found a posting that suggests that there is a conflict between
>>expat and apache. Expat is the XML parser that I believe is part of
>>libxml2
>>
>>
>>
> FYI, I do not know about libxml12 but I know that Expat is a base part
>for XML::Parser.
>
> I wish you luck with finding the cause of problems.
> Martin
>
>
>
From markw at illuminae.com Wed Mar 23 21:40:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed Mar 23 21:34:56 2005
Subject: [MOBY-dev] recompiling Apache
In-Reply-To:
References:
Message-ID: <424228A8.5040507@illuminae.com>
It seems to have settled down a bit now. All I did was install a newer
version of DBI!
There's still a segfault in the error log that happened some time in the
past 6 hours, but that is better than the several dozen per hour that
were happening a few days ago :-)
I'll keep an eye on it, but for now it seems somewhat stable (touch wood!)
M
Martin Senger wrote:
>>I've just found a posting that suggests that there is a conflict between
>>expat and apache. Expat is the XML parser that I believe is part of
>>libxml2
>>
>>
>>
> FYI, I do not know about libxml12 but I know that Expat is a base part
>for XML::Parser.
>
> I wish you luck with finding the cause of problems.
> Martin
>
>
>
From edward.kawas at gmail.com Tue Mar 29 11:24:44 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue Mar 29 11:18:48 2005
Subject: [MOBY-dev] Java packages conversation
In-Reply-To:
Message-ID: <4249814d.41902bab.69a1.43e9@mx.gmail.com>
Hi,
I have a structure that I would like comments and
suggestions on. Some of the code is neither yet documented
nor available on the cvs, but I was hoping to see what
everyone thinks anyways.
I basically used the 3 current packages (shared, client and
registry) and created some detailed packages underneath
them. I produced some java documentation and uploaded it to
http://bioinfo.icapture.ubc.ca/ekawas/doc/.
Thanks,
Eddie
From mwilkinson at mrl.ubc.ca Wed Mar 30 17:48:40 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 30 17:37:15 2005
Subject: [MOBY-dev] LSID's are running again :-)
Message-ID: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Hi all,
The LSID resolver for MOBY LSID's is up and running again thanks to
Eddie and with help and advice from Stephen Evanchik@IBM.
I've also written a little CGI form that will resolve a MOBY LSID to the
screen for viewing. This is available under the "Cool Tools" link from
the MOBY homepage.
Cheers all!
M
(reminder - just one more day to register for the MOBY meeting at a
discount rate!!)
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Wed Mar 30 19:04:27 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Wed Mar 30 18:59:12 2005
Subject: [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424B3E8B.5070607@cpsc.ucalgary.ca>
Hi All,
I am new to Moby. I followed the Fasta example service to create our
svervice. How do I register our service to Moby Centrol? could Anyone
let me know about?
Thanks,
Joyce
Mark Wilkinson wrote:
>Hi all,
>
>The LSID resolver for MOBY LSID's is up and running again thanks to
>Eddie and with help and advice from Stephen Evanchik@IBM.
>
>I've also written a little CGI form that will resolve a MOBY LSID to the
>screen for viewing. This is available under the "Cool Tools" link from
>the MOBY homepage.
>
>Cheers all!
>
>M
>
>(reminder - just one more day to register for the MOBY meeting at a
>discount rate!!)
>
>
>
>
From wangch at cpsc.ucalgary.ca Wed Mar 30 19:04:27 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Wed Mar 30 18:59:37 2005
Subject: [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424B3E8B.5070607@cpsc.ucalgary.ca>
Hi All,
I am new to Moby. I followed the Fasta example service to create our
svervice. How do I register our service to Moby Centrol? could Anyone
let me know about?
Thanks,
Joyce
Mark Wilkinson wrote:
>Hi all,
>
>The LSID resolver for MOBY LSID's is up and running again thanks to
>Eddie and with help and advice from Stephen Evanchik@IBM.
>
>I've also written a little CGI form that will resolve a MOBY LSID to the
>screen for viewing. This is available under the "Cool Tools" link from
>the MOBY homepage.
>
>Cheers all!
>
>M
>
>(reminder - just one more day to register for the MOBY meeting at a
>discount rate!!)
>
>
>
>
From mwilkinson at mrl.ubc.ca Wed Mar 30 19:18:06 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed Mar 30 19:06:56 2005
Subject: [moby] [MOBY-dev] How to register the service to Moby
In-Reply-To: <424B3E8B.5070607@cpsc.ucalgary.ca>
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
<424B3E8B.5070607@cpsc.ucalgary.ca>
Message-ID: <1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
Hi Joyce,
When you say "the Fasta example" which example do you mean? Can you
send the URL?
To answer your question - on this page:
http://www.biomoby.org/tutorials.html
there is a tutorial that includes information about how to register your
service in MOBY Central.
If you don't want to do it through code, there is also a web based GUI
written by Eddie Kawas that will help you register your service - you
can get to it by clicking the appropriate link from the Tools and Toys
page (http://www.biomoby.org/toolstoys.html).
Unfortunately, MOBY Central has just crashed... badly... and I need
someone to reboot it, but it is on the other side of the continent so it
might take a while until someone notices. As such, you will have to
wait for a while until you will be able to register your service. Sorry
about that! It doesn't happen very often...
Let me know if you need any more help.
Cheers!
Mark
On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
> Hi All,
> I am new to Moby. I followed the Fasta example service to create our
> svervice. How do I register our service to Moby Centrol? could Anyone
> let me know about?
> Thanks,
>
> Joyce
>
> Mark Wilkinson wrote:
>
> >Hi all,
> >
> >The LSID resolver for MOBY LSID's is up and running again thanks to
> >Eddie and with help and advice from Stephen Evanchik@IBM.
> >
> >I've also written a little CGI form that will resolve a MOBY LSID to the
> >screen for viewing. This is available under the "Cool Tools" link from
> >the MOBY homepage.
> >
> >Cheers all!
> >
> >M
> >
> >(reminder - just one more day to register for the MOBY meeting at a
> >discount rate!!)
> >
> >
> >
> >
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 13:38:08 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Thu Mar 31 13:32:10 2005
Subject: [moby] [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca> <424B3E8B.5070607@cpsc.ucalgary.ca>
<1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424C4390.5010305@cpsc.ucalgary.ca>
Hi Mark,
I say "the Fasta Example Service" which is at the URL:
http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
MobyEd_dispatcher.cgi for HMM search. I have a function for registering
service to Moby in the Hmm_test_central.pl.
I think when I run Hmm_test_central.pl, them HMM service will be
registered in Moby center. But I use the command line to check it, it is
not registered. I am not clear about this. Do we get any email from Moby
once the service is registered?
Anyway, Thank you for the information. I will check the tutorial again.
I guess that I may did not correct.
Regards,
Joyce
Mark Wilkinson wrote:
>Hi Joyce,
>
>When you say "the Fasta example" which example do you mean? Can you
>send the URL?
>
>To answer your question - on this page:
>http://www.biomoby.org/tutorials.html
>
>there is a tutorial that includes information about how to register your
>service in MOBY Central.
>
>If you don't want to do it through code, there is also a web based GUI
>written by Eddie Kawas that will help you register your service - you
>can get to it by clicking the appropriate link from the Tools and Toys
>page (http://www.biomoby.org/toolstoys.html).
>
>Unfortunately, MOBY Central has just crashed... badly... and I need
>someone to reboot it, but it is on the other side of the continent so it
>might take a while until someone notices. As such, you will have to
>wait for a while until you will be able to register your service. Sorry
>about that! It doesn't happen very often...
>
>Let me know if you need any more help.
>
>Cheers!
>
>Mark
>
>
>
>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>
>
>>Hi All,
>>I am new to Moby. I followed the Fasta example service to create our
>>svervice. How do I register our service to Moby Centrol? could Anyone
>>let me know about?
>>Thanks,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>Eddie and with help and advice from Stephen Evanchik@IBM.
>>>
>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>screen for viewing. This is available under the "Cool Tools" link from
>>>the MOBY homepage.
>>>
>>>Cheers all!
>>>
>>>M
>>>
>>>(reminder - just one more day to register for the MOBY meeting at a
>>>discount rate!!)
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
From mwilkinson at mrl.ubc.ca Thu Mar 31 13:50:21 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu Mar 31 13:38:46 2005
Subject: [moby] [MOBY-dev] How to register the service to Moby
In-Reply-To: <424C4390.5010305@cpsc.ucalgary.ca>
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
<424B3E8B.5070607@cpsc.ucalgary.ca>
<1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
<424C4390.5010305@cpsc.ucalgary.ca>
Message-ID: <1112295021.9268.10.camel@mobycentral.icapture.ubc.ca>
Hi Chunyan,
Please tell me where you found the link to that website - I am trying to
"squash" them all :-)
That particular tutorial, and the code modules that are described in it,
are significantly out of date, and *will not* result in functional
services under the new API.
Please follow the tutorial on the website that I sent you yesterday.
Unfortunately, MOBY Central has crashed AGAIN this morning so you will
not be able to register your service there until it is restarted... I
still have not found the source of these ongoing problems but the
crashes are getting worse - I can't even log in to that machine
anymore. If I cannot find the source of these problems by the end of
the week I will ask everyone to point their code at the mirror of MOBY
Central that I am running here in Vancouver, since it seems to be more
stable.
>>sigh<<
Cheers all
M
On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
> Hi Mark,
> I say "the Fasta Example Service" which is at the URL:
> http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
> I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
> MobyEd_dispatcher.cgi for HMM search. I have a function for registering
> service to Moby in the Hmm_test_central.pl.
> I think when I run Hmm_test_central.pl, them HMM service will be
> registered in Moby center. But I use the command line to check it, it is
> not registered. I am not clear about this. Do we get any email from Moby
> once the service is registered?
> Anyway, Thank you for the information. I will check the tutorial again.
> I guess that I may did not correct.
>
> Regards,
>
> Joyce
>
> Mark Wilkinson wrote:
>
> >Hi Joyce,
> >
> >When you say "the Fasta example" which example do you mean? Can you
> >send the URL?
> >
> >To answer your question - on this page:
> >http://www.biomoby.org/tutorials.html
> >
> >there is a tutorial that includes information about how to register your
> >service in MOBY Central.
> >
> >If you don't want to do it through code, there is also a web based GUI
> >written by Eddie Kawas that will help you register your service - you
> >can get to it by clicking the appropriate link from the Tools and Toys
> >page (http://www.biomoby.org/toolstoys.html).
> >
> >Unfortunately, MOBY Central has just crashed... badly... and I need
> >someone to reboot it, but it is on the other side of the continent so it
> >might take a while until someone notices. As such, you will have to
> >wait for a while until you will be able to register your service. Sorry
> >about that! It doesn't happen very often...
> >
> >Let me know if you need any more help.
> >
> >Cheers!
> >
> >Mark
> >
> >
> >
> >On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
> >
> >
> >>Hi All,
> >>I am new to Moby. I followed the Fasta example service to create our
> >>svervice. How do I register our service to Moby Centrol? could Anyone
> >>let me know about?
> >>Thanks,
> >>
> >>Joyce
> >>
> >>Mark Wilkinson wrote:
> >>
> >>
> >>
> >>>Hi all,
> >>>
> >>>The LSID resolver for MOBY LSID's is up and running again thanks to
> >>>Eddie and with help and advice from Stephen Evanchik@IBM.
> >>>
> >>>I've also written a little CGI form that will resolve a MOBY LSID to the
> >>>screen for viewing. This is available under the "Cool Tools" link from
> >>>the MOBY homepage.
> >>>
> >>>Cheers all!
> >>>
> >>>M
> >>>
> >>>(reminder - just one more day to register for the MOBY meeting at a
> >>>discount rate!!)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>MOBY-dev mailing list
> >>MOBY-dev@biomoby.org
> >>http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev@biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 15:30:36 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Thu Mar 31 15:24:57 2005
Subject: [moby] [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca> <424B3E8B.5070607@cpsc.ucalgary.ca> <1112228286.5297.11.camel@mobycentral.icapture.ubc.ca> <424C4390.5010305@cpsc.ucalgary.ca>
<1112295021.9268.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424C5DEC.50104@cpsc.ucalgary.ca>
Hi Mark,
I think I just found it on Google. I will check the tutorial on the
website that you sent to me yesterday. By the way, do you a sample of
codes in Perl (for new API)? If you have it, could you send them to me?
If you don't have, don't worry about it. I will find them in tutorial, I
guess.
Thanks,
Regards,
Chunyan or Joyce
Mark Wilkinson wrote:
>Hi Chunyan,
>
>Please tell me where you found the link to that website - I am trying to
>"squash" them all :-)
>
>That particular tutorial, and the code modules that are described in it,
>are significantly out of date, and *will not* result in functional
>services under the new API.
>
>Please follow the tutorial on the website that I sent you yesterday.
>
>Unfortunately, MOBY Central has crashed AGAIN this morning so you will
>not be able to register your service there until it is restarted... I
>still have not found the source of these ongoing problems but the
>crashes are getting worse - I can't even log in to that machine
>anymore. If I cannot find the source of these problems by the end of
>the week I will ask everyone to point their code at the mirror of MOBY
>Central that I am running here in Vancouver, since it seems to be more
>stable.
>
>
>
>>>sigh<<
>>>
>>>
>
>Cheers all
>
>M
>
>
>
>
>
>On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
>
>
>>Hi Mark,
>>I say "the Fasta Example Service" which is at the URL:
>>http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
>>I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
>>MobyEd_dispatcher.cgi for HMM search. I have a function for registering
>>service to Moby in the Hmm_test_central.pl.
>>I think when I run Hmm_test_central.pl, them HMM service will be
>>registered in Moby center. But I use the command line to check it, it is
>>not registered. I am not clear about this. Do we get any email from Moby
>>once the service is registered?
>>Anyway, Thank you for the information. I will check the tutorial again.
>>I guess that I may did not correct.
>>
>>Regards,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi Joyce,
>>>
>>>When you say "the Fasta example" which example do you mean? Can you
>>>send the URL?
>>>
>>>To answer your question - on this page:
>>>http://www.biomoby.org/tutorials.html
>>>
>>>there is a tutorial that includes information about how to register your
>>>service in MOBY Central.
>>>
>>>If you don't want to do it through code, there is also a web based GUI
>>>written by Eddie Kawas that will help you register your service - you
>>>can get to it by clicking the appropriate link from the Tools and Toys
>>>page (http://www.biomoby.org/toolstoys.html).
>>>
>>>Unfortunately, MOBY Central has just crashed... badly... and I need
>>>someone to reboot it, but it is on the other side of the continent so it
>>>might take a while until someone notices. As such, you will have to
>>>wait for a while until you will be able to register your service. Sorry
>>>about that! It doesn't happen very often...
>>>
>>>Let me know if you need any more help.
>>>
>>>Cheers!
>>>
>>>Mark
>>>
>>>
>>>
>>>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>>>
>>>
>>>
>>>
>>>>Hi All,
>>>>I am new to Moby. I followed the Fasta example service to create our
>>>>svervice. How do I register our service to Moby Centrol? could Anyone
>>>>let me know about?
>>>>Thanks,
>>>>
>>>>Joyce
>>>>
>>>>Mark Wilkinson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>>>Eddie and with help and advice from Stephen Evanchik@IBM.
>>>>>
>>>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>>>screen for viewing. This is available under the "Cool Tools" link from
>>>>>the MOBY homepage.
>>>>>
>>>>>Cheers all!
>>>>>
>>>>>M
>>>>>
>>>>>(reminder - just one more day to register for the MOBY meeting at a
>>>>>discount rate!!)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev@biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
From markw at illuminae.com Thu Mar 31 17:07:36 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu Mar 31 17:01:52 2005
Subject: [moby] [MOBY-dev] How to register the service to Moby
Message-ID: <212712647-1112306868-cardhu_blackberry.rim.net-32084-@engine11-cell01>
The tutorial has tons of code, and all of the services that I run have their code in the moby-live/Perl/scripts/Services/LocalServices.pm module in the cvs
That should get you started :-)
Cheers!
M
-----Original Message-----
From: Chunyan Wang
Date: Thu, 31 Mar 2005 13:30:36
To:Core developer announcements
Subject: Re: [moby] [MOBY-dev] How to register the service to Moby
Hi Mark,
I think I just found it on Google. I will check the tutorial on the
website that you sent to me yesterday. By the way, do you a sample of
codes in Perl (for new API)? If you have it, could you send them to me?
If you don't have, don't worry about it. I will find them in tutorial, I
guess.
Thanks,
Regards,
Chunyan or Joyce
Mark Wilkinson wrote:
>Hi Chunyan,
>
>Please tell me where you found the link to that website - I am trying to
>"squash" them all :-)
>
>That particular tutorial, and the code modules that are described in it,
>are significantly out of date, and *will not* result in functional
>services under the new API.
>
>Please follow the tutorial on the website that I sent you yesterday.
>
>Unfortunately, MOBY Central has crashed AGAIN this morning so you will
>not be able to register your service there until it is restarted... I
>still have not found the source of these ongoing problems but the
>crashes are getting worse - I can't even log in to that machine
>anymore. If I cannot find the source of these problems by the end of
>the week I will ask everyone to point their code at the mirror of MOBY
>Central that I am running here in Vancouver, since it seems to be more
>stable.
>
>
>
>>>sigh<<
>>>
>>>
>
>Cheers all
>
>M
>
>
>
>
>
>On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
>
>
>>Hi Mark,
>>I say "the Fasta Example Service" which is at the URL:
>>http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
>>I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
>>MobyEd_dispatcher.cgi for HMM search. I have a function for registering
>>service to Moby in the Hmm_test_central.pl.
>>I think when I run Hmm_test_central.pl, them HMM service will be
>>registered in Moby center. But I use the command line to check it, it is
>>not registered. I am not clear about this. Do we get any email from Moby
>>once the service is registered?
>>Anyway, Thank you for the information. I will check the tutorial again.
>>I guess that I may did not correct.
>>
>>Regards,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi Joyce,
>>>
>>>When you say "the Fasta example" which example do you mean? Can you
>>>send the URL?
>>>
>>>To answer your question - on this page:
>>>http://www.biomoby.org/tutorials.html
>>>
>>>there is a tutorial that includes information about how to register your
>>>service in MOBY Central.
>>>
>>>If you don't want to do it through code, there is also a web based GUI
>>>written by Eddie Kawas that will help you register your service - you
>>>can get to it by clicking the appropriate link from the Tools and Toys
>>>page (http://www.biomoby.org/toolstoys.html).
>>>
>>>Unfortunately, MOBY Central has just crashed... badly... and I need
>>>someone to reboot it, but it is on the other side of the continent so it
>>>might take a while until someone notices. As such, you will have to
>>>wait for a while until you will be able to register your service. Sorry
>>>about that! It doesn't happen very often...
>>>
>>>Let me know if you need any more help.
>>>
>>>Cheers!
>>>
>>>Mark
>>>
>>>
>>>
>>>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>>>
>>>
>>>
>>>
>>>>Hi All,
>>>>I am new to Moby. I followed the Fasta example service to create our
>>>>svervice. How do I register our service to Moby Centrol? could Anyone
>>>>let me know about?
>>>>Thanks,
>>>>
>>>>Joyce
>>>>
>>>>Mark Wilkinson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>>>Eddie and with help and advice from Stephen Evanchik@IBM.
>>>>>
>>>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>>>screen for viewing. This is available under the "Cool Tools" link from
>>>>>the MOBY homepage.
>>>>>
>>>>>Cheers all!
>>>>>
>>>>>M
>>>>>
>>>>>(reminder - just one more day to register for the MOBY meeting at a
>>>>>discount rate!!)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev@biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev@biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
_______________________________________________
MOBY-dev mailing list
MOBY-dev@biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
...on the road!
From smontgom at bcgsc.bc.ca Thu Mar 31 19:01:26 2005
From: smontgom at bcgsc.bc.ca (Stephen Montgomery)
Date: Thu Mar 31 18:50:05 2005
Subject: [MOBY-dev] moby data and parameters
Message-ID: <424C8F56.7080701@bcgsc.bc.ca>
hi -
does anyone have an example of a xml input where more than one dna
sequence is coming down the wire. is this a collection?
also, for a registered return data type we want to attach some
parameters (corresponding to the application that is going to be run).
is there a java example out there of doing this?
all the best,
stephen
ps ben and i had an awesome crash coding session yesterday. set-up the
plan, built the supports, now we just need to execute the vision. rock on.
From octave.noubibou at gsf.de Mon Mar 7 10:52:35 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Mon, 07 Mar 2005 16:52:35 +0100
Subject: [MOBY-dev] java api
In-Reply-To: <200502190736.j1J7aPKr002666@portal.open-bio.org>
References: <200502190736.j1J7aPKr002666@portal.open-bio.org>
Message-ID: <422C78C3.1020003@gsf.de>
Hi all,
as promised in my previous mail(see below), i have attached to this
message my source codes for parsing moby input xml .
The "RetrieveElementWS.java" class is just to show how you can use it.
your comments are welcome
octave
>
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>as Yan has mentioned, i have joined the PlaNet project at MIPS
>>>>since 3 months now. one of my first tasks was to provide a generic
>>>>API to simplify access to the pameters (queryID, namespace, id)
>>>>one needs from the moby input xml to run the services and also methods
>>>>to generate moby conform xml result.
>>>>
>>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>>purpose.
>>>>At the moment all you need to get your parameters is to use the method
>>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>>This method return a vector of the form e.g.:
>>>>
>>>>(((queryID1,ns,id))) for a simple type
>>>>
>>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>>collection
>>>>
>>>>or
>>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>>for an input with 2 invocations, the first been a collection and the
>>>>second a simple type.
>>>>
>>>>currently i do not handle secondary articles, but this should not be
>>>>difficult.
>>>>
>>>>we habe tried in our java services and everything seems to be ok.
>>>>
>>>>i am commenting the code now. once it is finished, i will like to
>>>>share it with you for comment or rectification and of course use.
>>>>Is there any possibility to upload this in central repository?
>>>>
>>>>best regards
>>>>
>>>>octave
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericInputParser.java
Type: text/x-java
Size: 11797 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/GenericInputParser-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetInputDataForQuery.java
Type: text/x-java
Size: 2581 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/GetInputDataForQuery-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericMobyOutputwriter.java
Type: text/x-java
Size: 14047 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/GenericMobyOutputwriter-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RetrieveElementWS.java
Type: text/x-java
Size: 6154 bytes
Desc: not available
Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20050307/c0c1ce38/RetrieveElementWS-0002.bin
From mwilkinson at mrl.ubc.ca Mon Mar 7 12:40:04 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 07 Mar 2005 09:40:04 -0800
Subject: [MOBY-dev] Registration for the May 7/8 BioMOBY meeting in Vancouver
Message-ID: <1110217204.3898.418.camel@mobycentral.icapture.ubc.ca>
Hi all,
I've set up a CGI form for registration. Please submit your
registration ASAP so that I can complete the budget for the meeting. I
will be doing my best to supplement your room and food from my grant so
that your travel will be the primary expense to you.
http://biomoby.org/cgi-bin/register.cgi
Cheers! See you all in Vancouver!
Mark
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Tue Mar 8 19:54:59 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Mar 2005 16:54:59 -0800
Subject: [MOBY-dev] bug fix (??) for collection inputs/outputs
Message-ID: <1110329699.9567.11.camel@mobycentral.icapture.ubc.ca>
I've claimed that before on this bug, but it seems to be an unusually
pesky one! Anyway, the next attempt has just been committed.
I **think** that database entries for collection objects should now,
properly, write a service_instance_id of NULL into the database for
their simple_input/output tables. The problem has been that they have
been writing "0" and this causes them to not show up in the XML service
signature from a findService call.
If you are running your own MOBY Central you will need to update the
database by hand... again... sorry! I thought I had killed this one
months ago, but apparently not.
update simple_input set service_instance_id=NULL where
service_instance_id=0
(same for simple_output)
my apologies again!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Fri Mar 11 16:25:54 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Fri, 11 Mar 2005 22:25:54 +0100
Subject: [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
Message-ID: <42320CE2.3040201@cnb.uam.es>
Hi MOBYfiers!
I think I have found a bug in
MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
nodes. When getNodeContentWithArticle is handling nodes with its content
encapsulated in a CDATA section (for instance, a Blast result, a
sequence with a description, or an XML content), it ignores it. So, any
perl service which uses this function would not be able to get the
content when any MOBY client uses CDATA to maintain the original layout.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Fri Mar 11 17:15:05 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri, 11 Mar 2005 14:15:05 -0800
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <42320CE2.3040201@cnb.uam.es>
References: <42320CE2.3040201@cnb.uam.es>
Message-ID: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Committed a fix - try it now.
M
On Fri, 2005-03-11 at 13:25, José María Fernández González wrote:
> Hi MOBYfiers!
> I think I have found a bug in
> MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
> nodes. When getNodeContentWithArticle is handling nodes with its content
> encapsulated in a CDATA section (for instance, a Blast result, a
> sequence with a description, or an XML content), it ignores it. So, any
> perl service which uses this function would not be able to get the
> content when any MOBY client uses CDATA to maintain the original layout.
>
> Best Regards,
> José María
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Fri Mar 11 17:15:05 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri, 11 Mar 2005 14:15:05 -0800
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <42320CE2.3040201@cnb.uam.es>
References: <42320CE2.3040201@cnb.uam.es>
Message-ID: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Committed a fix - try it now.
M
On Fri, 2005-03-11 at 13:25, José María Fernández González wrote:
> Hi MOBYfiers!
> I think I have found a bug in
> MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
> nodes. When getNodeContentWithArticle is handling nodes with its content
> encapsulated in a CDATA section (for instance, a Blast result, a
> sequence with a description, or an XML content), it ignores it. So, any
> perl service which uses this function would not be able to get the
> content when any MOBY client uses CDATA to maintain the original layout.
>
> Best Regards,
> José María
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Mon Mar 14 10:41:13 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 14 Mar 2005 16:41:13 +0100
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
References: <42320CE2.3040201@cnb.uam.es>
<1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Message-ID: <4235B099.402@cnb.uam.es>
Yes, it works!
Thanks, Mark!!
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From jmfernandez at cnb.uam.es Mon Mar 14 10:54:30 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 14 Mar 2005 16:54:30 +0100
Subject: [MOBY-dev] About serviceNotes block
Message-ID: <4235B3B6.7090508@cnb.uam.es>
Hi again, MOBYfiers!
I am exploring the use of the serviceNotes block, and from the BioMOBY
v0.8 documents I have understood that only textual (human readable)
content should go inside it. Would it be a BioMOBY protocol violation if
I use it to send some XML content? I want to use it to communicate some
warnings related to services which answer a collection, and I want to
separate warnings from different answers (I don't want to go back to
flat file world!).
Also, I think I have found a possible bug in the current implementation
of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
getNodeContentWithArticle.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Mon Mar 14 13:55:30 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 14 Mar 2005 10:55:30 -0800
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235B3B6.7090508@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
Message-ID: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 07:54, José María Fernández González wrote:
> Also, I think I have found a possible bug in the current implementation
> of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
> getNodeContentWithArticle.
fixed. Let me know if it is still a problem.
> Would it be a BioMOBY protocol violation if
> I use it to send some XML content? I want to use it to communicate some
> warnings related to services which answer a collection, and I want to
> separate warnings from different answers (I don't want to go back to
> flat file world!).
to be honest, we haven't thought much about what should/not go into that
block. It was intentionally left ambiguous so that we could discuss it
at some point in the future. It appears that the point has now come!
My gut is that we should not just stick raw XML in there, since that
isn't very MOBYesque... the MOBYesque way would be to make another
ontology :-) A "commentary ontology" or something like that - then wrap
your XML according to its type.
what kinds of information do you have in your XML?
Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
provision information data? Do you have a defined set of predicates for
that?
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Mon Mar 14 13:55:30 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 14 Mar 2005 10:55:30 -0800
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235B3B6.7090508@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
Message-ID: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 07:54, José María Fernández González wrote:
> Also, I think I have found a possible bug in the current implementation
> of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
> getNodeContentWithArticle.
fixed. Let me know if it is still a problem.
> Would it be a BioMOBY protocol violation if
> I use it to send some XML content? I want to use it to communicate some
> warnings related to services which answer a collection, and I want to
> separate warnings from different answers (I don't want to go back to
> flat file world!).
to be honest, we haven't thought much about what should/not go into that
block. It was intentionally left ambiguous so that we could discuss it
at some point in the future. It appears that the point has now come!
My gut is that we should not just stick raw XML in there, since that
isn't very MOBYesque... the MOBYesque way would be to make another
ontology :-) A "commentary ontology" or something like that - then wrap
your XML according to its type.
what kinds of information do you have in your XML?
Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
provision information data? Do you have a defined set of predicates for
that?
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Mon Mar 14 16:03:38 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 14 Mar 2005 22:03:38 +0100
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
Message-ID: <4235FC2A.9030807@cnb.uam.es>
>
> fixed. Let me know if it is still a problem.
>
Okay, getServiceNotes works with CDATA.
> what kinds of information do you have in your XML?
>
Well, something like the next one. This is an example from INB
(http://www.inab.org) guys, which are stretching BioMOBY to its limits.
You should note they are using a different namespace, so they are
avoiding past, present and future XML tag collisions:
incomplete_outputIntAct DB engine was not
available
Looking at the example, the structure is describing that answer with
queryID 'b2' could be incomplete because some of the used databases was
not available at runtime. INB prefers serviceNotes block instead of
ProvisionInformation block because most of the warnings, and in general,
exception information, comprise the whole output, which is a Collection
for some services.
The other drawback for ProvisionInformation is that it cannot appear in
a mobyData outside any object, or even Simple or Collection
declarations, so it becomes useless when you want (or need) to notify
some information related to a Collection, or there is no answer at all
because there was a problem with that query.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Mon Mar 14 16:27:29 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 14 Mar 2005 13:27:29 -0800
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235FC2A.9030807@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
<4235FC2A.9030807@cnb.uam.es>
Message-ID: <1110835649.29060.127.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 13:03, José María Fernández González wrote:
> INB prefers serviceNotes block instead of
> ProvisionInformation block because most of the warnings, and in general,
> exception information, comprise the whole output, which is a Collection
> for some services.
That's an interesting observation - I hadn't thought about that. The
reason for the ProvisionInformation block being a part of an object was
so that different subcomponents of a complex object could potentially
have different provision annotations... however you rightly point out
that this would all have to be duplicated if these were part of a
collection, and that it would be more efficient to have it at that
level.
The serviceNotes block is the place where I had intended for this
"global" type of information to be placed - we just need to agree on a
format.
> The other drawback for ProvisionInformation is that it cannot appear in
> a mobyData outside any object, or even Simple or Collection
> declarations, so it becomes useless when you want (or need) to notify
> some information related to a Collection,
I like the provision information block where it is for the reasons I
indicate above, but I tend to agree with you that there is possibly a
need for one additional level of provider feedback (I have to point out,
however, that as far as I know you and I are the only people who are
using these extra parts of the MOBY message ;-) )
> or there is no answer at all
> because there was a problem with that query.
It was intended that a blank mobyData node would indicate a "problem",
but it is not possible to differentiate between a problematic query, and
the lack of an answer to a valid query at this level. Since the whole
MOBY thing is intended to be accessed by machines, we would have had to
build (or re-build) a large vocabulary of possible error messages in
order to create a machine-readable solution to errors at this level of
resolution... and since we cannot reasonably predict all of the possible
errors to the level of resolution required for a machine to fix the
problem on its own, this seemed a bit futile... so I didn't bother.
A blank mobyData block means "I don't know what you are talking about" -
for whatever reason; it may be, but it is not necessarily an error.
This is something we could re-visit at the next MOBY meeting, however.
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Tue Mar 15 19:09:37 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 15 Mar 2005 16:09:37 -0800
Subject: [MOBY-dev] REGISATRATION CALL #2 MOBY-DIC meeting
Message-ID: <1110931777.3201.18.camel@mobycentral.icapture.ubc.ca>
Hi all,
Just re-pinging everyone who wants to come to Vancouver for the MOBY DIC
meeting in May (7/8). PLEASE REGISTER AS SOON AS POSSIBLE at:
http://www.biomoby.org/cgi-bin/register.cgi
I am pretty sure now that I will be able to cover 100% of your housing
costs, and probably some of the meal costs as well. I'm still working
out the final budget, but I do need to know how many people are coming
before I can come up with the final number.
My current guesstimate is that the registration fees (to cover your room
for up to three nights, and breakfast + lunch on the two meeting days)
will be about CAD$200. I will try to bring that even lower if I can!
Cheers!
Mark
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Wed Mar 16 09:01:35 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 16 Mar 2005 15:01:35 +0100
Subject: [MOBY-dev] Some Perl warnings in registerService with secondaries
Message-ID: <42383C3F.9070102@cnb.uam.es>
Hi MOBYfiers!
after some tests with registerService and a service definition with
secondaries, I have realized that you have to declare an empty list of
enums in each secondary parameter, so the method registers your service.
Also, even when a secondary parameter does not have minimum, maximum or
default value, the method uses it internally, and so the warnings are
ocurring.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 946.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 948.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 949.
As I have seen inside the code, it seems registerService submits all
these fields to MOBY Central, even when they have not been declared.
But, it should not do it... Is it perhaps a bug?
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From markw at illuminae.com Wed Mar 16 10:42:42 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 16 Mar 2005 09:42:42 -0600
Subject: [unclassified] [MOBY-dev] Some Perl warnings in registerService
with secondaries
In-Reply-To: <42383C3F.9070102@cnb.uam.es>
References: <42383C3F.9070102@cnb.uam.es>
Message-ID: <423853F2.2040307@illuminae.com>
Hi Jos?,
Thanks for the bug report! I'm glad someone else is using the secondary
parameter code - up to now, I think only our friends at the Pasteur
institute were using them, but the more eyes/fingers we have testing
these the better!
Could you please do a CVS update so that your error messages line up
with the current codebase? that will make it easier to debug. e.g. in
my copy of the code, line 948 is blank, so it should not be throwing the
error you indicate below.
I will continue exploring the problem until I hear back from you.
Cheers!
M
Jos? Mar?a Fern?ndez Gonz?lez wrote:
> Hi MOBYfiers!
> after some tests with registerService and a service definition
> with secondaries, I have realized that you have to declare an empty
> list of enums in each secondary parameter, so the method registers
> your service. Also, even when a secondary parameter does not have
> minimum, maximum or default value, the method uses it internally, and
> so the warnings are ocurring.
>
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 946.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 948.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 949.
>
> As I have seen inside the code, it seems registerService submits
> all these fields to MOBY Central, even when they have not been
> declared. But, it should not do it... Is it perhaps a bug?
>
> Best Regards,
> Jos? Mar?a
From jmfernandez at cnb.uam.es Wed Mar 16 11:15:22 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 16 Mar 2005 17:15:22 +0100
Subject: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <423853F2.2040307@illuminae.com>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
Message-ID: <42385B9A.9070803@cnb.uam.es>
Hi Mark,
I have made a cvs update -dP and my moby-live copy was already
up-to-date. I am using the default branch and server
(cvs at cvs.open-bio.org:/home/repository/moby). Are you talking about
another different branch/server?
Cheers,
Jos? Mar?a
Mark Wilkinson wrote:
> Hi Jos?,
>
> Thanks for the bug report! I'm glad someone else is using the secondary
> parameter code - up to now, I think only our friends at the Pasteur
> institute were using them, but the more eyes/fingers we have testing
> these the better!
>
> Could you please do a CVS update so that your error messages line up
> with the current codebase? that will make it easier to debug. e.g. in
> my copy of the code, line 948 is blank, so it should not be throwing the
> error you indicate below.
>
> I will continue exploring the problem until I hear back from you.
>
> Cheers!
>
> M
>
>
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Wed Mar 16 13:11:38 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 10:11:38 -0800
Subject: [moby] Re: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <42385B9A.9070803@cnb.uam.es>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
<42385B9A.9070803@cnb.uam.es>
Message-ID: <1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
hmmmmm.... I think I am working on HEAD. I just did a fresh checkout
and I still get the lines you indicate as either blank or commented-out
in that copy as well.
??
Anyway, I will try to reproduce the problem first, and if I can
reproduce it, I'll debug it and commit the changes to HEAD. Then we
should see if you are able to update these into your version.
Cheers!
M
On Wed, 2005-03-16 at 08:15, José María Fernández González wrote:
> Hi Mark,
> I have made a cvs update -dP and my moby-live copy was already
> up-to-date. I am using the default branch and server
> (cvs at cvs.open-bio.org:/home/repository/moby). Are you talking about
> another different branch/server?
>
> Cheers,
> José María
>
> Mark Wilkinson wrote:
> > Hi José,
> >
> > Thanks for the bug report! I'm glad someone else is using the secondary
> > parameter code - up to now, I think only our friends at the Pasteur
> > institute were using them, but the more eyes/fingers we have testing
> > these the better!
> >
> > Could you please do a CVS update so that your error messages line up
> > with the current codebase? that will make it easier to debug. e.g. in
> > my copy of the code, line 948 is blank, so it should not be throwing the
> > error you indicate below.
> >
> > I will continue exploring the problem until I hear back from you.
> >
> > Cheers!
> >
> > M
> >
> >
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 13:18:13 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 10:18:13 -0800
Subject: [moby] Re: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
<42385B9A.9070803@cnb.uam.es>
<1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110997093.6585.26.camel@mobycentral.icapture.ubc.ca>
D'OH!
Me being stupid (actually, my editor being stupid, but me not noticing)
We're working on the same code, and I can replicate your error.
Fixing it now...
M
On Wed, 2005-03-16 at 10:11, Mark Wilkinson wrote:
> hmmmmm.... I think I am working on HEAD. I just did a fresh checkout
> and I still get the lines you indicate as either blank or commented-out
> in that copy as well.
>
> ??
>
> Anyway, I will try to reproduce the problem first, and if I can
> reproduce it, I'll debug it and commit the changes to HEAD. Then we
> should see if you are able to update these into your version.
>
> Cheers!
>
> M
>
>
> On Wed, 2005-03-16 at 08:15, José María Fernández González wrote:
> > Hi Mark,
> > I have made a cvs update -dP and my moby-live copy was already
> > up-to-date. I am using the default branch and server
> > (cvs at cvs.open-bio.org:/home/repository/moby). Are you talking about
> > another different branch/server?
> >
> > Cheers,
> > José María
> >
> > Mark Wilkinson wrote:
> > > Hi José,
> > >
> > > Thanks for the bug report! I'm glad someone else is using the secondary
> > > parameter code - up to now, I think only our friends at the Pasteur
> > > institute were using them, but the more eyes/fingers we have testing
> > > these the better!
> > >
> > > Could you please do a CVS update so that your error messages line up
> > > with the current codebase? that will make it easier to debug. e.g. in
> > > my copy of the code, line 948 is blank, so it should not be throwing the
> > > error you indicate below.
> > >
> > > I will continue exploring the problem until I hear back from you.
> > >
> > > Cheers!
> > >
> > > M
> > >
> > >
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 14:02:44 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 11:02:44 -0800
Subject: [MOBY-dev] My bad! database strucural change needed.
Message-ID: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
To everyone running a local MOBY Central:
We need to update the table structure for MOBY Central in light of the
bug fix for Jose's reported bug this morning. Sorry everyone!
mysql> alter table secondary_input modify datatype varchar(20);
It was not recording secondary datatypes properly. There was only one
instance of an incorrect record in the public registry database and I
was able to fix that one by hand. Hopefully it should be similarly
simple for everyone else.
I'm committing the code changes to the CVS right now.
what colour is MY red face?! :-)
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 14:05:01 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 11:05:01 -0800
Subject: [MOBY-dev] NIX THAT was Re: My bad! database strucural change
needed.
In-Reply-To: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
References: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
NIX THAT LAST MESSAGE - it was the test instance of MOBY Central that
was defective, the production instance is correct.
...>>sigh<<.... bad day for debugging...
M
On Wed, 2005-03-16 at 11:02, Mark Wilkinson wrote:
> To everyone running a local MOBY Central:
>
> We need to update the table structure for MOBY Central in light of the
> bug fix for Jose's reported bug this morning. Sorry everyone!
>
> mysql> alter table secondary_input modify datatype varchar(20);
>
> It was not recording secondary datatypes properly. There was only one
> instance of an incorrect record in the public registry database and I
> was able to fix that one by hand. Hopefully it should be similarly
> simple for everyone else.
>
> I'm committing the code changes to the CVS right now.
>
> what colour is MY red face?! :-)
>
> M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 14:05:01 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 11:05:01 -0800
Subject: [MOBY-dev] NIX THAT was Re: My bad! database strucural change
needed.
In-Reply-To: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
References: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
NIX THAT LAST MESSAGE - it was the test instance of MOBY Central that
was defective, the production instance is correct.
...>>sigh<<.... bad day for debugging...
M
On Wed, 2005-03-16 at 11:02, Mark Wilkinson wrote:
> To everyone running a local MOBY Central:
>
> We need to update the table structure for MOBY Central in light of the
> bug fix for Jose's reported bug this morning. Sorry everyone!
>
> mysql> alter table secondary_input modify datatype varchar(20);
>
> It was not recording secondary datatypes properly. There was only one
> instance of an incorrect record in the public registry database and I
> was able to fix that one by hand. Hopefully it should be similarly
> simple for everyone else.
>
> I'm committing the code changes to the CVS right now.
>
> what colour is MY red face?! :-)
>
> M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From edward.kawas at gmail.com Wed Mar 16 15:18:01 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed, 16 Mar 2005 12:18:01 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Hi,
I was wondering if people could let me know what version of
Java people are using. I was hoping to see if we could
somehow push everyone towards using 1.5 in the near future.
I know the upgrade isn't trivial, so I was hoping to hear
your comments.
Thanks,
Eddie
From edward.kawas at gmail.com Wed Mar 16 15:18:01 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed, 16 Mar 2005 12:18:01 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Hi,
I was wondering if people could let me know what version of
Java people are using. I was hoping to see if we could
somehow push everyone towards using 1.5 in the near future.
I know the upgrade isn't trivial, so I was hoping to hear
your comments.
Thanks,
Eddie
From bmg at sfu.ca Wed Mar 16 15:48:20 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 16 Mar 2005 12:48:20 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <42389B94.3070106@sfu.ca>
Happy to move on to 1.5, would be helpful for some of the things I'm doing.
-Ben
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
From gordonp at ucalgary.ca Wed Mar 16 16:11:33 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 16 Mar 2005 14:11:33 -0700
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389B94.3070106@sfu.ca>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
<42389B94.3070106@sfu.ca>
Message-ID: <4238A105.2050701@ucalgary.ca>
I haven't played around with 1.5 much yet, as I haven't needed its new
features (I'm using 1.4.2). I think that if the existing MOBY code
works fine in 1.5, we should move forward and let people use Generics,
etc. in the codebase. Better to do this transition before even more
people are developing code...
Benjamin Good wrote:
> Happy to move on to 1.5, would be helpful for some of the things I'm
> doing.
>
> -Ben
>
> Eddie Kawas wrote:
>
>> Hi,
>>
>> I was wondering if people could let me know what version of
>> Java people are using. I was hoping to see if we could
>> somehow push everyone towards using 1.5 in the near future.
>> I know the upgrade isn't trivial, so I was hoping to hear
>> your comments.
>>
>> Thanks,
>>
>> Eddie
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
From ywong at infobiogen.fr Thu Mar 17 04:03:41 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Thu, 17 Mar 2005 10:03:41 +0100
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <423947ED.9090103@infobiogen.fr>
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
java 1.4.2 and java 1.5
From octave.noubibou at gsf.de Thu Mar 17 05:12:44 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Thu, 17 Mar 2005 11:12:44 +0100
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <4239581C.9030909@gsf.de>
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
hi Eddie,
currently, we are using 1.4.2. i hoppe it should not be a big problem to
move to 1.5 if needed.
octave
From tmo at ebi.ac.uk Thu Mar 17 08:13:48 2005
From: tmo at ebi.ac.uk (Tom Oinn)
Date: Thu, 17 Mar 2005 13:13:48 +0000
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <4239581C.9030909@gsf.de>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
<4239581C.9030909@gsf.de>
Message-ID: <4239828C.2070602@ebi.ac.uk>
Octave Noubibou wrote:
> Eddie Kawas wrote:
>
>> Hi,
>>
>> I was wondering if people could let me know what version of
>> Java people are using. I was hoping to see if we could
>> somehow push everyone towards using 1.5 in the near future.
>> I know the upgrade isn't trivial, so I was hoping to hear
>> your comments.
Highly non trivial, are you using Axis? We've pretty much given up on
1.5 until the axis devs get their act together as right now it won't
work. We're using 1.4.2_07 for Taverna
Cheers,
Tom
From senger at ebi.ac.uk Mon Mar 21 09:44:31 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 21 Mar 2005 14:44:31 +0000 (GMT)
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID:
> I was wondering if people could let me know what version of
> Java people are using. I was hoping to see if we could
> somehow push everyone towards using 1.5 in the near future.
>
There will never be a single date when people can stop using the old
version and start to use the new version. Therefore, there should be
some "transitional rules" to follow. The rules must be both for
the compilation and run-time. Here is how it perhaps can work:
a) The run-time is completely up to the code developer. If [s]he
insists (needs) to use newer Java 1.5 his/her code should be written in a
way that it throws an exception if run under older JVM.
b) The compilation time can be solved by having Java version checks in
Ant. Ant is prepared for it, and I can make it into jMoby build.xml. So if
you have a code, that you wish to commit to jMoby and this code requires
1.5. please send it first to me and I will make the changes in build.xml.
b1) There may be other targets in Ant (other than compilation) that
depend on Java version - such as deploying web services under Axis (as
pointed out Tom). I can also help with version checking for such targets
if you let me know (at the moment there is no such target in build.xml).
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From edward.kawas at gmail.com Mon Mar 21 12:01:44 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Mon, 21 Mar 2005 09:01:44 -0800
Subject: [MOBY-dev] Java packages conversation
Message-ID: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Hi,
Martin & I thought that our conversation might interest
others in the list, so here it is:
------------Eddie-------------------
Hi,
I have been trying to think of a package hierarchy that
would be useful for jMoby now and in the future. I have come
up with the following draft, and was hoping for criticism.
Below you will find the package structure I think might
work:
#######################
org.biomoby.central.
registry.
retrieval.
_to_be_named_later.
register
deregister
client.
perlConverts.
execution.
invocation
ui.
commandline.
graphical.
swing
applets
servlets.
lsid
jResource
plugins.
taverna
dom.
testing.
###########################
Anything that you think is missing? I hope to be able to
slot the current classes into these packages a little at a
time.
In the package perlConverts I was hoping to slot in java
versions of Perl scripts that have been already created,
like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
cgi-bin/types/Namespaces.
In the package dom, I thought that people may be comfortable
with a particular version of dom (w3c.dom, jDom, etc) and so
I thought it might be nice to separate implementations.
I think that the rest of the hierarchy is pretty straight
forward and doesn't need explanation, although I could be
wrong.
Also, I do not have as much knowledge about Moby as many of
you do and I may have missed some obvious things, so please
let me know.
Thanks,
Eddie Kawas
------------Martin----------------
Thanks for the overview.
I have just a few questions:
1) Does the new proposal require changes in the current
(existing) packages? If yes, in which?
2) Are you going to create package 'slots' now - and only
later to populate them, or are you proposing to create them
only when you have something to be there?
3) perlConverts: I do not feel comfortable with this
name. Do users need to know (from the package name) the
reason why a package was created?
I think that better is to name a package by its
functionality, not by the origin. But again, I would perhaps
let people to create their package names in a less
structured (less detailed) way than you are proposing (which
I will explain when I have answers for the two previous
questions)
- so if somebody wants to keep te origin in the package
name, I am not basically against it. Let's return to these
comments later.
4)
> In the package dom, I thought that people may be
comfortable with a
> particular version of dom (w3c.dom, jDom, etc) and so I
thought it
> might be nice to separate implementations.
>
Again, I think that this details should be (if one wants
to have several separate implementations) *below* package
where a dom is used. You ut it under 'client' - but what if
I need to use a dom in a class belonging to a registry
package, or to a commandLine package? The 'dom'
name should be there - in more than one place.
> I think that the rest of the hierarchy is pretty straight
forward and
> doesn't need explanation, although I could be wrong.
>
5)
Well, if you publish rules you need to explain them
anyway. So why not to do it now :-) It would be good to have
few lines defineg what should go into individual packages.
Cheers,
Martin
-------------Eddie--------------
> 1) Does the new proposal require changes in the current
> (existing)
> packages? If yes, in which?
Yes, however, I am not sure which classes will be moved
where. I tried to see what classes we had and then I tried
to create a slot that it might fit into.
> 2) Are you going to create package 'slots' now - and
only later to
> populate them, or are you proposing to create them only
when you have
> something to be there?
I was thinking of creating them now. Is this a bad idea?
> 3) perlConverts: I do not feel comfortable with this
name.
I agree. I think I did that out of sheer laziness.
> 4)
> > In the package dom ...
You are right, this should be below a package when DOM is
used, not in client.
Thanks,
Eddie
------------Martin----------------
> > 1) Does the new proposal require changes in the
current
> > (existing)
> > packages? If yes, in which?
> Yes, however, I am not sure which classes will be moved
where.
>
Well, I am reluctant to make these changes - at least in
the code written (mainly) by me - unless there is a good
reason for that. Changes in package names (in existing code)
are evil - if the code is already used by others. Sorry for
that...
> > 2) Are you going to create package 'slots' now - and
only later
> > to populate them, or are you proposing to create them
only when you
> > have something to be there?
> I was thinking of creating them now. Is this a bad idea?
>
I always liked such idea - but (in my experiences) it
simply never worked (unless you are in a strict industrial
environment). Therefore, I suggest to live with a compromise
- to "dictate" only relatively high-level package names, and
let people to create their own below.
Therefore, I have started only with
org.biomoby.[client|shared|registry] - and we need possibly
something for support for service providers (I am using now
org.biomoby.service - but there are only some testing
classes now).
Having said that, I think it is a good idea to write a
document - and to publish it on the jMoby pages - that would
suggest what package names (below the ones I mentioned
above) could be used for specific purposes.
But not to create them in advance, and not to enforce it
later. Just like hints. As always with hints, people will
follow them if the hints are well explained and known to
people.
Let me know if you are uncomfortable with the high-level
package names as they exist now - and let's discuss what to
do with them. BTW, your
proposal:
org.biomoby.central.
registry.
retrieval.
_to_be_named_later.
register
deregister
cannot work easily. Simply because it is too detailed. There
may be classes (such as CentralImpl) that work cross the
packages you defined.
No, I would definitely keep this part simpler - just
org.biomoby.registry.
(But this was just an example, let's discuss it.)
Cheers,
Martin
--------------Eddie---------------
So you don't think that we should try and create a more
detailed hierarchy. I thought that one would be nice,
because we were stumbling upon users that had created almost
duplicate code to that which was in jMoby. Ultimately, I was
hoping to reduce code duplication in order to get people
more on their way to doing useful things.
I realize that changing package names is going to be messy,
so we were proposing to do it slowly, maybe a package at a
time with advance warnings. We could have even tried
automating it with scripts that contain the mappings of
where current classes are and where they would be after the
'refactor'-ing.
What do you think?
Eddie
PS: I am all for creating a document that outlines what
should be placed where, etc.
------------Martin----------------
> I thought that one would be nice, because we were
stumbling upon users
> that had created almost duplicate code to that which was
in jMoby.
>
This is obviously bad and we should perhaps contact these
people and try to convince them to re-use existing code (I
am working now, for example, with Sophie Durand
to convince her to re-use some
exiting code for her classes). But I believe that changing
package names will not help to achieve it. We need different
ways to convince them.
> We could have even tried automating it with scripts that
contain the
> mappings of where current classes are and where they would
be after
> the 'refactor'-ing.
>
I agree that it would be useful to provide a refactoring
tool - if we need to refactor. But, as I said, I do not
think that refactoring will help us now.
Sorry for not agreeing with you on the package name
changes. But I still believe that providing hints how to
name their code would be very helpful.
Martin
PS. Btw, feel free to reproduce our conversation on the
biomoby-dev list if you wish. M.
--
Martin Senger
-----------Eddie-------------
Thanks for your comments, I think that I should rethink this
whole issue and then get back to you.
Eddie
From edward.kawas at gmail.com Mon Mar 21 12:14:34 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Mon, 21 Mar 2005 09:14:34 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To:
Message-ID: <423f00fb.14d19c85.67e0.0ec1@mx.gmail.com>
Martin,
May I ask you what it was you thought would be placed in the
packages client, shared, and registry when you created them?
Thanks,
Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Monday, March 21, 2005 6:45 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] What versions of JAVA is everyone
> using?
>
> > I was wondering if people could let me know what version
> of
> > Java people are using. I was hoping to see if we could
> > somehow push everyone towards using 1.5 in the near
> future.
> >
> There will never be a single date when people can stop
> using the old
> version and start to use the new version. Therefore, there
> should be
> some "transitional rules" to follow. The rules must be
> both for
> the compilation and run-time. Here is how it perhaps can
> work:
>
> a) The run-time is completely up to the code developer.
> If [s]he
> insists (needs) to use newer Java 1.5 his/her code should
> be written in a
> way that it throws an exception if run under older JVM.
>
> b) The compilation time can be solved by having Java
> version checks in
> Ant. Ant is prepared for it, and I can make it into jMoby
> build.xml. So if
> you have a code, that you wish to commit to jMoby and this
> code requires
> 1.5. please send it first to me and I will make the
> changes in build.xml.
>
> b1) There may be other targets in Ant (other than
> compilation) that
> depend on Java version - such as deploying web services
> under Axis (as
> pointed out Tom). I can also help with version checking
> for such targets
> if you let me know (at the moment there is no such target
> in build.xml).
>
> Cheers,
> Martin
>
> --
> Martin Senger
>
> EMBL Outstation - Hinxton Senger at EBI.ac.uk
> European Bioinformatics Institute Phone: (+44) 1223
> 494636
> Wellcome Trust Genome Campus (Switchboard:
> 494444)
> Hinxton Fax : (+44) 1223
> 494468
> Cambridge CB10 1SD
> United Kingdom
> http://industry.ebi.ac.uk/~senger
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
From gordonp at ucalgary.ca Mon Mar 21 12:35:10 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon, 21 Mar 2005 10:35:10 -0700
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
References: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Message-ID: <423F05CE.1060801@ucalgary.ca>
Hi Eddie,
A couple of thoughts:
-What about the data templates and instances? Is org.biomoby.shared
going away? Should there be a org.biomoby.data instead?
-Where should server side or combines server/client objects (e.g.
MobyRequest) go?
>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
> client.
> perlConverts.
> execution.
> invocation
> ui.
> commandline.
> graphical.
> swing
> applets
> servlets.
> lsid
> jResource
> plugins.
> taverna
> dom.
> testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong.
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
> Thanks for the overview.
> I have just a few questions:
>
> 1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
> 2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
> 3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
> 4)
>
>
>>In the package dom, I thought that people may be
>>
>>
>comfortable with a
>
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>
>>
>thought it
>
>
>>might be nice to separate implementations.
>>
>>
>>
> Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom'
>name should be there - in more than one place.
>
>
>
>>I think that the rest of the hierarchy is pretty straight
>>
>>
>forward and
>
>
>>doesn't need explanation, although I could be wrong.
>>
>>
>>
> 5)
> Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
> Cheers,
> Martin
>
>-------------Eddie--------------
>
>
>
>> 1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>
>
>> 2) Are you going to create package 'slots' now - and
>>
>>
>only later to
>
>
>>populate them, or are you proposing to create them only
>>
>>
>when you have
>
>
>>something to be there?
>>
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>
>
>> 3) perlConverts: I do not feel comfortable with this
>>
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>
>
>> 4)
>>
>>
>>>In the package dom ...
>>>
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>
>
>>> 1) Does the new proposal require changes in the
>>>
>>>
>current
>
>
>>>(existing)
>>>packages? If yes, in which?
>>>
>>>
>>Yes, however, I am not sure which classes will be moved
>>
>>
>where.
>
>
> Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>
>
>>> 2) Are you going to create package 'slots' now - and
>>>
>>>
>only later
>
>
>>>to populate them, or are you proposing to create them
>>>
>>>
>only when you
>
>
>>>have something to be there?
>>>
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>
>>
> I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
> Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
> Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined.
>No, I would definitely keep this part simpler - just
>org.biomoby.registry.
>(But this was just an example, let's discuss it.)
>
> Cheers,
> Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>
>
>>I thought that one would be nice, because we were
>>
>>
>stumbling upon users
>
>
>>that had created almost duplicate code to that which was
>>
>>
>in jMoby.
>
>
> This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>
>
>>We could have even tried automating it with scripts that
>>
>>
>contain the
>
>
>>mappings of where current classes are and where they would
>>
>>
>be after
>
>
>>the 'refactor'-ing.
>>
>>
>>
> I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
>
> Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
> Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
From ywong at infobiogen.fr Tue Mar 22 03:46:10 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Tue, 22 Mar 2005 09:46:10 +0100
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
References: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Message-ID: <423FDB52.1000603@infobiogen.fr>
Eddie Kawas wrote:
>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
> client.
> perlConverts.
> execution.
> invocation
> ui.
> commandline.
> graphical.
> swing
> applets
> servlets.
> lsid
> jResource
> plugins.
> taverna
> dom.
> testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong.
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
> Thanks for the overview.
> I have just a few questions:
>
> 1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
> 2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
> 3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
> 4)
>
>
>>In the package dom, I thought that people may be
>>
>>
>comfortable with a
>
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>
>>
>thought it
>
>
>>might be nice to separate implementations.
>>
>>
>>
> Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom'
>name should be there - in more than one place.
>
>
>
>>I think that the rest of the hierarchy is pretty straight
>>
>>
>forward and
>
>
>>doesn't need explanation, although I could be wrong.
>>
>>
>>
> 5)
> Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
> Cheers,
> Martin
>
>-------------Eddie--------------
>
>
>
>> 1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>
>
>> 2) Are you going to create package 'slots' now - and
>>
>>
>only later to
>
>
>>populate them, or are you proposing to create them only
>>
>>
>when you have
>
>
>>something to be there?
>>
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>
>
>> 3) perlConverts: I do not feel comfortable with this
>>
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>
>
>> 4)
>>
>>
>>>In the package dom ...
>>>
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>
>
>>> 1) Does the new proposal require changes in the
>>>
>>>
>current
>
>
>>>(existing)
>>>packages? If yes, in which?
>>>
>>>
>>Yes, however, I am not sure which classes will be moved
>>
>>
>where.
>
>
> Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>
>
>>> 2) Are you going to create package 'slots' now - and
>>>
>>>
>only later
>
>
>>>to populate them, or are you proposing to create them
>>>
>>>
>only when you
>
>
>>>have something to be there?
>>>
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>
>>
> I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
> Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
> Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined.
>No, I would definitely keep this part simpler - just
>org.biomoby.registry.
>(But this was just an example, let's discuss it.)
>
> Cheers,
> Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>
>
>>I thought that one would be nice, because we were
>>
>>
>stumbling upon users
>
>
>>that had created almost duplicate code to that which was
>>
>>
>in jMoby.
>
>
> This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>
>
>>We could have even tried automating it with scripts that
>>
>>
>contain the
>
>
>>mappings of where current classes are and where they would
>>
>>
>be after
>
>
>>the 'refactor'-ing.
>>
>>
>>
> I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
>
> Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
> Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
How about some ant tasks that would make registration to the central
possible in a build file?
From senger at ebi.ac.uk Tue Mar 22 04:23:53 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 09:23:53 +0000 (GMT)
Subject: Ant tasks (was: [MOBY-dev] Java packages conversation)
In-Reply-To: <423FDB52.1000603@infobiogen.fr>
Message-ID:
> How about some ant tasks that would make registration to the central
> possible in a build file?
>
It is surely possible, but Ant is not helpful too much in this case -
at least I think:
The registration can be achieved by calling MobyCmdLineClient - and
this can be done perfectly from Ant (Ant task can easily set CLASSPATH and
call a Java application - MobyCmdLineClient is a Java application, of
course). The problem starts with the parameters for this application (and
there may be really *many* parameters for the registration). I have not
find a way how to pass to an Ant target parameters from the Ant's
command-line (let me know please if anybody knows how to do it).
Therefore, you have to expressed all parameters as Java properties, let
Ant to put them in a file and then feed an application (it can be again a
slightly modified MobyCmdLineClient, here is no problem) from this file.
So you have to do a lot of writing (setting properties) before you invoke
Ant - perhaps the same amount but I guess even more than writing a short
script where you can put all your registration parameters directly.
That's why I think that Ant is not too helpful for making registration.
But if people think that it should be there I can make such Ant target.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From ywong at infobiogen.fr Tue Mar 22 05:30:05 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Tue, 22 Mar 2005 11:30:05 +0100
Subject: [MOBY-dev] Re: Ant tasks
In-Reply-To:
References:
Message-ID: <423FF3AD.2030000@infobiogen.fr>
Martin Senger wrote:
>>How about some ant tasks that would make registration to the central
>>possible in a build file?
>>
>>
>>
> It is surely possible, but Ant is not helpful too much in this case -
>at least I think:
> The registration can be achieved by calling MobyCmdLineClient - and
>this can be done perfectly from Ant (Ant task can easily set CLASSPATH and
>call a Java application - MobyCmdLineClient is a Java application, of
>course). The problem starts with the parameters for this application (and
>there may be really *many* parameters for the registration). I have not
>find a way how to pass to an Ant target parameters from the Ant's
>command-line (let me know please if anybody knows how to do it).
>Therefore, you have to expressed all parameters as Java properties, let
>Ant to put them in a file and then feed an application (it can be again a
>slightly modified MobyCmdLineClient, here is no problem) from this file.
>So you have to do a lot of writing (setting properties) before you invoke
>Ant - perhaps the same amount but I guess even more than writing a short
>script where you can put all your registration parameters directly.
> That's why I think that Ant is not too helpful for making registration.
>But if people think that it should be there I can make such Ant target.
>
> Cheers,
> Martin
>
>
>
I thought it was possible to add registration tasks as bioMoby
registration requests are XML.
Something like could exit in an ant build file:
Maybe we do not need to fully translate a request in an ant like syntax
but make the ant task understand the moby request
An ant task would look like this:
mobyPhytoprotGetByAGICodeRetrievalgenoplante-info.infobiogen.frhttp://genoplante-info.infobiogen.fr/webservices/phytoprot-planet.pygpsupport at infobiogen.fr0Access to Phytoprot's clusters, by accession
numberObjectAGI_LocusCodeStringAvsAAvsAAvsP
It would use the existant bioMoby XML syntax to describes tasks/parameters.
Regards
Yan
From senger at ebi.ac.uk Tue Mar 22 06:05:53 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 11:05:53 +0000 (GMT)
Subject: [MOBY-dev] Java packages conversation (was: What versions of
JAVA is everyone using?)
In-Reply-To: <423f00fb.14d19c85.67e0.0ec1@mx.gmail.com>
Message-ID:
> May I ask you what it was you thought would be placed in the
> packages client, shared, and registry when you created them?
>
Sure. (I am quoting partly from the jMoby API documentation. And I am
going to put these more detailed answers back there.)
Just a note (repeating what was already said in this thread): these are
meant to be high-level package names - and everybody is welcome to make
more specialized packages *within* (below) these packages. However, please
be aware that making a directory under CVS is a *big* change which is hard
to redo - so think twice before you commit a new directory.
'org.biomoby.clients' contains components used to develop Moby clients.
The Moby clients can be both clients of the Moby registry and clients of
the Moby services. It can also contain not only components but full
clients (even though I have put my full command-line client
MobyCmdLineClient elsewhere because of some obscure reasons I have not
put that client into any package).
'org.biomoby.registry' contains components helping with Moby registry.
These components are supposed to be used by those who are running a
registry. At the moment, there is not many components here, because most
of the registry implementation is in Perl. Note that if you write code
that *uses* registry by calling its API methods you should put it into the
'org.biomoby.client' package because in fact you are the clients of the
registry. Here should go components that use direct access to the registry
databases (like a direct JDBC access), or here we may have
Java-implementation of the whole registry soemday.
'org.biomoby.service' (which should be called actually better
'org.biomoby.services' - my fault) contains general components that can be
used by those writing code for moby services. This is not meant to be used
for the service-specific code - such some business logic to get to a plant
database at MIPS (for that I assume the developer will have his/her own
package name which is not committed to the jMoby CVS) - but for general
components that can be re-used by any/many service providers for their
services. Also here can go some example services that can be used as
templates for service providers.
And finally 'org.biomoby.shared' contains components that are used by
classes from more than one package above. The bottom-line (or a
bottom-rule) is: If one wants to run clients, it must be sufficent for him
to pack all classes from 'org.biomoby.client' *and* 'org.biomoby.shared'
only. If one wants to create a registry oriented component, it is enough
for him to pack 'org.biomoby.registry' *and* 'org.biomoby.shared'. And
similarly for service providers which would pack ''org.biomoby.service'
*and* 'org.biomoby.shared'.
Additionally the 'org.biomoby.shared' package is a good place for
putting there Java interfaces - assuming that they are expected to use
more generally. So I have put here Central.java - an interface defining an
access to a Moby registry - because I felt (and I still feel) that there
may be a component (using this interface) in other package than in
'org.biomoby.client'.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Tue Mar 22 06:40:03 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 11:40:03 +0000 (GMT)
Subject: [MOBY-dev] Re: Ant tasks
In-Reply-To: <423FF3AD.2030000@infobiogen.fr>
Message-ID:
> Something like could exit in an ant build file:
>
Thanks for your example. I apologize but I strongly oppose it. And I am
sorry that I perhaps have not expressed things clearly. There are two
arguments why your example should not be put, as it was suggested, into
Ant's build.xml (and I am talking about the build.xml distributed in jMoby
CVS; if you talk about your own build.xml somewhere in your local copy of
jMoby, your example is perfectly fine):
1) The build.xml is a general file that is used by anybody building
jMoby and using jMoby. So it cannot have specific things dealing with a
particular service, such as
PhytoprotGetByAGICode. One *can* have such
things in an Ant's build.xml if it is defined as a property - and one is
free to define his/her own properties either on Ant command line, or in a
local build.properties file. So your example would be something like:
${service.name}
and you have to put into your build.properties file a line:
service.name = PhytoprotGetByAGICode
or you would invoke jMoby Ant by typing:
./build-dev.sh -Dservice.name=PhytoprotGetByAGICode register
But considering how many properties one needs to set, it would be a lot of
writing - that's what I was talkeing about in my previous mail.
2) This is not a strong argument - and there may be other opinions on
that - but I feel like this: In jMoby (and AFAIK it is the same within the
perl moby libraries), you are encouraged not to use directly XML requested
by Moby registry but rather to use an API to access such registry. In
jMoby case it is a Java API defined in Central.java. Using this, you are
shared by potential changes in the native (XML-based) Moby API. Therefore,
I would not recommed to register your services by defining XML at all (not
only as a part of an Ant's build.xml).
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Tue Mar 22 07:12:17 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 12:12:17 +0000 (GMT)
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423F05CE.1060801@ucalgary.ca>
Message-ID:
> -What about the data templates and instances?
>
What are data templates and instances?
> Is org.biomoby.shared going away? Should there be a org.biomoby.data
> instead?
>
I hope I have explained things in my previous email.
'org.biomoby.shared' will stay (as far as I can tell). If you feel a need
for a sub-package containing data structure feel free to create
'org.biomoby.shared.data' (but at the moment I am not going to move there
any of my data classes - simple, as explained earlier, it is too many
changes in the users code which is not justified now - I believe).
> -Where should server side or combines server/client objects (e.g.
> MobyRequest) go?
>
Why do you think that MobyRequest is a server/client combination? Do
you mean perhaps service/client combination? If that is the case, I think
this class should be in 'org.biomoby.shared' (or it its subpackage of your
choice). If this class is used only by clients (when they call a moby
service) then it should go to 'org.biomoby.client'.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From gss at ncgr.org Tue Mar 22 13:46:09 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 22 Mar 2005 11:46:09 -0700
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424067F1.10603@ncgr.org>
Not at the moment, but it does seem important to have a place to return
error messages. It is particularly important in a distributed
environment, since there are so many things that can go wrong
(transmission errors, servers being down, ...).
// Gary
Mark Wilkinson wrote:
>Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
>provision information data? Do you have a defined set of predicates for
>that?
>
From senger at ebi.ac.uk Wed Mar 23 10:24:12 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 23 Mar 2005 15:24:12 +0000 (GMT)
Subject: [MOBY-dev] problems with Moby central
In-Reply-To: <1110906365.2107.18.camel@mobycentral.icapture.ubc.ca>
Message-ID:
Mark,
It seems that the Moby Central is broken at the moment. It cannot even
return a list of services. Instead it reports about an XML parse
exception. Would you mind to look at it please?
Many thanks,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From mwilkinson at mrl.ubc.ca Wed Mar 23 11:05:45 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 23 Mar 2005 08:05:45 -0800
Subject: [MOBY-dev] mobycentral revived
Message-ID: <1111593945.22484.18.camel@mobycentral.icapture.ubc.ca>
Hi all,
sorry about that - I was in post-surgery with my cat when it went down
and I never got back on-line until this AM.
MOBY Central is a bit flaky at the moment, and we can't figure out why.
It is a rather sudden flakyness that doesn't seem to correspond to any
particular change we have made. The Apache error logs fill up with
segfaults within a couple of hours and that crashes the system as the
amount of available memory goes to zero. MySQL seems to be having a
similar problem (it was mysql that had crashed last night). This all
seems to point to a physical memory error, but we can't detect one...
It may be time to get a new machine for MOBY :-)
Anyway, I'll keep an eye on it throughout the day. I have turned
apache's error logging to "critical" to reduce teh number of error
messages, so hopefully we'll have longer availability between crashes.
Sorry about this!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 23 11:53:44 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 23 Mar 2005 08:53:44 -0800
Subject: [MOBY-dev] recompiling Apache
Message-ID: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Hi everyone,
I've just found a posting that suggests that there is a conflict between
expat and apache. Expat is the XML parser that I believe is part of
libxml2 which is what is used by XML::LibXML - the new libraries that
are doing the XML parsing for MOBY Central.
I will need to recompile Apache to fix this problem (if it is the
problem...), so you might notice mobycentral going up and down over the
next 48 hours as I play with it, but I will try to limit my testing to
the test instance of the server so that it doesn't disturb anyone too
badly.
Sorry for the flakyness!
M
(this doesn't explain the crash of mysql... but it might just have been
a coincidence...)
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 23 15:43:07 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 23 Mar 2005 12:43:07 -0800
Subject: [MOBY-dev] Cut-off for MOBY-DIC registration: March 31, 2005.
Message-ID: <1111610587.24448.12.camel@mobycentral.icapture.ubc.ca>
Hi all,
Particularly pinging the S-MOBY crew, the CSHL crew, the Brisbane crew,
and anyone from myGrid or GO who wants to spend a few days away from the
dull Manchester/Hinxton rain lapping up the sun in Lotus Land :-) If
you have not registered yet, go to:
http://biomoby.org/cgi-bin/register.cgi
In order to make a budget and book the catering I have to set a cut-off
date for the MOBY DIC meeting registration. March 31st will be the last
date for attendees who want to take advantage of the substantially
discounted registration supplement from my Genome Canada grant, after
which you will be responsible for paying your own room and board.
So... if you haven't already registered... get on y'r horse! :-)
If you aren't sure if you have registered, go to
http://biomoby.org/regisrations.txt
I will make the final budget on the 1st of April and then will be able
to let you know exactly what the registration fees will be (including 3
nights and breakfast/lunch and coffee breaks for the the meeting days).
I'm still expecting this to be under $200, probably well under that
number.
Cheers all!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From senger at ebi.ac.uk Wed Mar 23 19:09:24 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 24 Mar 2005 00:09:24 +0000 (GMT)
Subject: [MOBY-dev] recompiling Apache
In-Reply-To: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Message-ID:
> I've just found a posting that suggests that there is a conflict between
> expat and apache. Expat is the XML parser that I believe is part of
> libxml2
>
FYI, I do not know about libxml12 but I know that Expat is a base part
for XML::Parser.
I wish you luck with finding the cause of problems.
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Wed Mar 23 19:09:24 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 24 Mar 2005 00:09:24 +0000 (GMT)
Subject: [MOBY-dev] recompiling Apache
In-Reply-To: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Message-ID:
> I've just found a posting that suggests that there is a conflict between
> expat and apache. Expat is the XML parser that I believe is part of
> libxml2
>
FYI, I do not know about libxml12 but I know that Expat is a base part
for XML::Parser.
I wish you luck with finding the cause of problems.
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From markw at illuminae.com Wed Mar 23 21:40:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 23 Mar 2005 18:40:40 -0800
Subject: [MOBY-dev] recompiling Apache
In-Reply-To:
References:
Message-ID: <424228A8.5040507@illuminae.com>
It seems to have settled down a bit now. All I did was install a newer
version of DBI!
There's still a segfault in the error log that happened some time in the
past 6 hours, but that is better than the several dozen per hour that
were happening a few days ago :-)
I'll keep an eye on it, but for now it seems somewhat stable (touch wood!)
M
Martin Senger wrote:
>>I've just found a posting that suggests that there is a conflict between
>>expat and apache. Expat is the XML parser that I believe is part of
>>libxml2
>>
>>
>>
> FYI, I do not know about libxml12 but I know that Expat is a base part
>for XML::Parser.
>
> I wish you luck with finding the cause of problems.
> Martin
>
>
>
From markw at illuminae.com Wed Mar 23 21:40:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 23 Mar 2005 18:40:40 -0800
Subject: [MOBY-dev] recompiling Apache
In-Reply-To:
References:
Message-ID: <424228A8.5040507@illuminae.com>
It seems to have settled down a bit now. All I did was install a newer
version of DBI!
There's still a segfault in the error log that happened some time in the
past 6 hours, but that is better than the several dozen per hour that
were happening a few days ago :-)
I'll keep an eye on it, but for now it seems somewhat stable (touch wood!)
M
Martin Senger wrote:
>>I've just found a posting that suggests that there is a conflict between
>>expat and apache. Expat is the XML parser that I believe is part of
>>libxml2
>>
>>
>>
> FYI, I do not know about libxml12 but I know that Expat is a base part
>for XML::Parser.
>
> I wish you luck with finding the cause of problems.
> Martin
>
>
>
From edward.kawas at gmail.com Tue Mar 29 11:24:44 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 29 Mar 2005 08:24:44 -0800
Subject: [MOBY-dev] Java packages conversation
In-Reply-To:
Message-ID: <4249814d.41902bab.69a1.43e9@mx.gmail.com>
Hi,
I have a structure that I would like comments and
suggestions on. Some of the code is neither yet documented
nor available on the cvs, but I was hoping to see what
everyone thinks anyways.
I basically used the 3 current packages (shared, client and
registry) and created some detailed packages underneath
them. I produced some java documentation and uploaded it to
http://bioinfo.icapture.ubc.ca/ekawas/doc/.
Thanks,
Eddie
From mwilkinson at mrl.ubc.ca Wed Mar 30 17:48:40 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 30 Mar 2005 14:48:40 -0800
Subject: [MOBY-dev] LSID's are running again :-)
Message-ID: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Hi all,
The LSID resolver for MOBY LSID's is up and running again thanks to
Eddie and with help and advice from Stephen Evanchik at IBM.
I've also written a little CGI form that will resolve a MOBY LSID to the
screen for viewing. This is available under the "Cool Tools" link from
the MOBY homepage.
Cheers all!
M
(reminder - just one more day to register for the MOBY meeting at a
discount rate!!)
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Wed Mar 30 19:04:27 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Wed, 30 Mar 2005 17:04:27 -0700
Subject: [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424B3E8B.5070607@cpsc.ucalgary.ca>
Hi All,
I am new to Moby. I followed the Fasta example service to create our
svervice. How do I register our service to Moby Centrol? could Anyone
let me know about?
Thanks,
Joyce
Mark Wilkinson wrote:
>Hi all,
>
>The LSID resolver for MOBY LSID's is up and running again thanks to
>Eddie and with help and advice from Stephen Evanchik at IBM.
>
>I've also written a little CGI form that will resolve a MOBY LSID to the
>screen for viewing. This is available under the "Cool Tools" link from
>the MOBY homepage.
>
>Cheers all!
>
>M
>
>(reminder - just one more day to register for the MOBY meeting at a
>discount rate!!)
>
>
>
>
From wangch at cpsc.ucalgary.ca Wed Mar 30 19:04:27 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Wed, 30 Mar 2005 17:04:27 -0700
Subject: [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424B3E8B.5070607@cpsc.ucalgary.ca>
Hi All,
I am new to Moby. I followed the Fasta example service to create our
svervice. How do I register our service to Moby Centrol? could Anyone
let me know about?
Thanks,
Joyce
Mark Wilkinson wrote:
>Hi all,
>
>The LSID resolver for MOBY LSID's is up and running again thanks to
>Eddie and with help and advice from Stephen Evanchik at IBM.
>
>I've also written a little CGI form that will resolve a MOBY LSID to the
>screen for viewing. This is available under the "Cool Tools" link from
>the MOBY homepage.
>
>Cheers all!
>
>M
>
>(reminder - just one more day to register for the MOBY meeting at a
>discount rate!!)
>
>
>
>
From mwilkinson at mrl.ubc.ca Wed Mar 30 19:18:06 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 30 Mar 2005 16:18:06 -0800
Subject: [moby] [MOBY-dev] How to register the service to Moby
In-Reply-To: <424B3E8B.5070607@cpsc.ucalgary.ca>
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
<424B3E8B.5070607@cpsc.ucalgary.ca>
Message-ID: <1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
Hi Joyce,
When you say "the Fasta example" which example do you mean? Can you
send the URL?
To answer your question - on this page:
http://www.biomoby.org/tutorials.html
there is a tutorial that includes information about how to register your
service in MOBY Central.
If you don't want to do it through code, there is also a web based GUI
written by Eddie Kawas that will help you register your service - you
can get to it by clicking the appropriate link from the Tools and Toys
page (http://www.biomoby.org/toolstoys.html).
Unfortunately, MOBY Central has just crashed... badly... and I need
someone to reboot it, but it is on the other side of the continent so it
might take a while until someone notices. As such, you will have to
wait for a while until you will be able to register your service. Sorry
about that! It doesn't happen very often...
Let me know if you need any more help.
Cheers!
Mark
On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
> Hi All,
> I am new to Moby. I followed the Fasta example service to create our
> svervice. How do I register our service to Moby Centrol? could Anyone
> let me know about?
> Thanks,
>
> Joyce
>
> Mark Wilkinson wrote:
>
> >Hi all,
> >
> >The LSID resolver for MOBY LSID's is up and running again thanks to
> >Eddie and with help and advice from Stephen Evanchik at IBM.
> >
> >I've also written a little CGI form that will resolve a MOBY LSID to the
> >screen for viewing. This is available under the "Cool Tools" link from
> >the MOBY homepage.
> >
> >Cheers all!
> >
> >M
> >
> >(reminder - just one more day to register for the MOBY meeting at a
> >discount rate!!)
> >
> >
> >
> >
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 13:38:08 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Thu, 31 Mar 2005 11:38:08 -0700
Subject: [moby] [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca> <424B3E8B.5070607@cpsc.ucalgary.ca>
<1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424C4390.5010305@cpsc.ucalgary.ca>
Hi Mark,
I say "the Fasta Example Service" which is at the URL:
http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
MobyEd_dispatcher.cgi for HMM search. I have a function for registering
service to Moby in the Hmm_test_central.pl.
I think when I run Hmm_test_central.pl, them HMM service will be
registered in Moby center. But I use the command line to check it, it is
not registered. I am not clear about this. Do we get any email from Moby
once the service is registered?
Anyway, Thank you for the information. I will check the tutorial again.
I guess that I may did not correct.
Regards,
Joyce
Mark Wilkinson wrote:
>Hi Joyce,
>
>When you say "the Fasta example" which example do you mean? Can you
>send the URL?
>
>To answer your question - on this page:
>http://www.biomoby.org/tutorials.html
>
>there is a tutorial that includes information about how to register your
>service in MOBY Central.
>
>If you don't want to do it through code, there is also a web based GUI
>written by Eddie Kawas that will help you register your service - you
>can get to it by clicking the appropriate link from the Tools and Toys
>page (http://www.biomoby.org/toolstoys.html).
>
>Unfortunately, MOBY Central has just crashed... badly... and I need
>someone to reboot it, but it is on the other side of the continent so it
>might take a while until someone notices. As such, you will have to
>wait for a while until you will be able to register your service. Sorry
>about that! It doesn't happen very often...
>
>Let me know if you need any more help.
>
>Cheers!
>
>Mark
>
>
>
>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>
>
>>Hi All,
>>I am new to Moby. I followed the Fasta example service to create our
>>svervice. How do I register our service to Moby Centrol? could Anyone
>>let me know about?
>>Thanks,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>Eddie and with help and advice from Stephen Evanchik at IBM.
>>>
>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>screen for viewing. This is available under the "Cool Tools" link from
>>>the MOBY homepage.
>>>
>>>Cheers all!
>>>
>>>M
>>>
>>>(reminder - just one more day to register for the MOBY meeting at a
>>>discount rate!!)
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
From mwilkinson at mrl.ubc.ca Thu Mar 31 13:50:21 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 31 Mar 2005 10:50:21 -0800
Subject: [moby] [MOBY-dev] How to register the service to Moby
In-Reply-To: <424C4390.5010305@cpsc.ucalgary.ca>
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
<424B3E8B.5070607@cpsc.ucalgary.ca>
<1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
<424C4390.5010305@cpsc.ucalgary.ca>
Message-ID: <1112295021.9268.10.camel@mobycentral.icapture.ubc.ca>
Hi Chunyan,
Please tell me where you found the link to that website - I am trying to
"squash" them all :-)
That particular tutorial, and the code modules that are described in it,
are significantly out of date, and *will not* result in functional
services under the new API.
Please follow the tutorial on the website that I sent you yesterday.
Unfortunately, MOBY Central has crashed AGAIN this morning so you will
not be able to register your service there until it is restarted... I
still have not found the source of these ongoing problems but the
crashes are getting worse - I can't even log in to that machine
anymore. If I cannot find the source of these problems by the end of
the week I will ask everyone to point their code at the mirror of MOBY
Central that I am running here in Vancouver, since it seems to be more
stable.
>>sigh<<
Cheers all
M
On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
> Hi Mark,
> I say "the Fasta Example Service" which is at the URL:
> http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
> I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
> MobyEd_dispatcher.cgi for HMM search. I have a function for registering
> service to Moby in the Hmm_test_central.pl.
> I think when I run Hmm_test_central.pl, them HMM service will be
> registered in Moby center. But I use the command line to check it, it is
> not registered. I am not clear about this. Do we get any email from Moby
> once the service is registered?
> Anyway, Thank you for the information. I will check the tutorial again.
> I guess that I may did not correct.
>
> Regards,
>
> Joyce
>
> Mark Wilkinson wrote:
>
> >Hi Joyce,
> >
> >When you say "the Fasta example" which example do you mean? Can you
> >send the URL?
> >
> >To answer your question - on this page:
> >http://www.biomoby.org/tutorials.html
> >
> >there is a tutorial that includes information about how to register your
> >service in MOBY Central.
> >
> >If you don't want to do it through code, there is also a web based GUI
> >written by Eddie Kawas that will help you register your service - you
> >can get to it by clicking the appropriate link from the Tools and Toys
> >page (http://www.biomoby.org/toolstoys.html).
> >
> >Unfortunately, MOBY Central has just crashed... badly... and I need
> >someone to reboot it, but it is on the other side of the continent so it
> >might take a while until someone notices. As such, you will have to
> >wait for a while until you will be able to register your service. Sorry
> >about that! It doesn't happen very often...
> >
> >Let me know if you need any more help.
> >
> >Cheers!
> >
> >Mark
> >
> >
> >
> >On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
> >
> >
> >>Hi All,
> >>I am new to Moby. I followed the Fasta example service to create our
> >>svervice. How do I register our service to Moby Centrol? could Anyone
> >>let me know about?
> >>Thanks,
> >>
> >>Joyce
> >>
> >>Mark Wilkinson wrote:
> >>
> >>
> >>
> >>>Hi all,
> >>>
> >>>The LSID resolver for MOBY LSID's is up and running again thanks to
> >>>Eddie and with help and advice from Stephen Evanchik at IBM.
> >>>
> >>>I've also written a little CGI form that will resolve a MOBY LSID to the
> >>>screen for viewing. This is available under the "Cool Tools" link from
> >>>the MOBY homepage.
> >>>
> >>>Cheers all!
> >>>
> >>>M
> >>>
> >>>(reminder - just one more day to register for the MOBY meeting at a
> >>>discount rate!!)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>MOBY-dev mailing list
> >>MOBY-dev at biomoby.org
> >>http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 15:30:36 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Thu, 31 Mar 2005 13:30:36 -0700
Subject: [moby] [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca> <424B3E8B.5070607@cpsc.ucalgary.ca> <1112228286.5297.11.camel@mobycentral.icapture.ubc.ca> <424C4390.5010305@cpsc.ucalgary.ca>
<1112295021.9268.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424C5DEC.50104@cpsc.ucalgary.ca>
Hi Mark,
I think I just found it on Google. I will check the tutorial on the
website that you sent to me yesterday. By the way, do you a sample of
codes in Perl (for new API)? If you have it, could you send them to me?
If you don't have, don't worry about it. I will find them in tutorial, I
guess.
Thanks,
Regards,
Chunyan or Joyce
Mark Wilkinson wrote:
>Hi Chunyan,
>
>Please tell me where you found the link to that website - I am trying to
>"squash" them all :-)
>
>That particular tutorial, and the code modules that are described in it,
>are significantly out of date, and *will not* result in functional
>services under the new API.
>
>Please follow the tutorial on the website that I sent you yesterday.
>
>Unfortunately, MOBY Central has crashed AGAIN this morning so you will
>not be able to register your service there until it is restarted... I
>still have not found the source of these ongoing problems but the
>crashes are getting worse - I can't even log in to that machine
>anymore. If I cannot find the source of these problems by the end of
>the week I will ask everyone to point their code at the mirror of MOBY
>Central that I am running here in Vancouver, since it seems to be more
>stable.
>
>
>
>>>sigh<<
>>>
>>>
>
>Cheers all
>
>M
>
>
>
>
>
>On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
>
>
>>Hi Mark,
>>I say "the Fasta Example Service" which is at the URL:
>>http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
>>I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
>>MobyEd_dispatcher.cgi for HMM search. I have a function for registering
>>service to Moby in the Hmm_test_central.pl.
>>I think when I run Hmm_test_central.pl, them HMM service will be
>>registered in Moby center. But I use the command line to check it, it is
>>not registered. I am not clear about this. Do we get any email from Moby
>>once the service is registered?
>>Anyway, Thank you for the information. I will check the tutorial again.
>>I guess that I may did not correct.
>>
>>Regards,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi Joyce,
>>>
>>>When you say "the Fasta example" which example do you mean? Can you
>>>send the URL?
>>>
>>>To answer your question - on this page:
>>>http://www.biomoby.org/tutorials.html
>>>
>>>there is a tutorial that includes information about how to register your
>>>service in MOBY Central.
>>>
>>>If you don't want to do it through code, there is also a web based GUI
>>>written by Eddie Kawas that will help you register your service - you
>>>can get to it by clicking the appropriate link from the Tools and Toys
>>>page (http://www.biomoby.org/toolstoys.html).
>>>
>>>Unfortunately, MOBY Central has just crashed... badly... and I need
>>>someone to reboot it, but it is on the other side of the continent so it
>>>might take a while until someone notices. As such, you will have to
>>>wait for a while until you will be able to register your service. Sorry
>>>about that! It doesn't happen very often...
>>>
>>>Let me know if you need any more help.
>>>
>>>Cheers!
>>>
>>>Mark
>>>
>>>
>>>
>>>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>>>
>>>
>>>
>>>
>>>>Hi All,
>>>>I am new to Moby. I followed the Fasta example service to create our
>>>>svervice. How do I register our service to Moby Centrol? could Anyone
>>>>let me know about?
>>>>Thanks,
>>>>
>>>>Joyce
>>>>
>>>>Mark Wilkinson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>>>Eddie and with help and advice from Stephen Evanchik at IBM.
>>>>>
>>>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>>>screen for viewing. This is available under the "Cool Tools" link from
>>>>>the MOBY homepage.
>>>>>
>>>>>Cheers all!
>>>>>
>>>>>M
>>>>>
>>>>>(reminder - just one more day to register for the MOBY meeting at a
>>>>>discount rate!!)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev at biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
From markw at illuminae.com Thu Mar 31 17:07:36 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 31 Mar 2005 22:07:36 +0000 GMT
Subject: [moby] [MOBY-dev] How to register the service to Moby
Message-ID: <212712647-1112306868-cardhu_blackberry.rim.net-32084-@engine11-cell01>
The tutorial has tons of code, and all of the services that I run have their code in the moby-live/Perl/scripts/Services/LocalServices.pm module in the cvs
That should get you started :-)
Cheers!
M
-----Original Message-----
From: Chunyan Wang
Date: Thu, 31 Mar 2005 13:30:36
To:Core developer announcements
Subject: Re: [moby] [MOBY-dev] How to register the service to Moby
Hi Mark,
I think I just found it on Google. I will check the tutorial on the
website that you sent to me yesterday. By the way, do you a sample of
codes in Perl (for new API)? If you have it, could you send them to me?
If you don't have, don't worry about it. I will find them in tutorial, I
guess.
Thanks,
Regards,
Chunyan or Joyce
Mark Wilkinson wrote:
>Hi Chunyan,
>
>Please tell me where you found the link to that website - I am trying to
>"squash" them all :-)
>
>That particular tutorial, and the code modules that are described in it,
>are significantly out of date, and *will not* result in functional
>services under the new API.
>
>Please follow the tutorial on the website that I sent you yesterday.
>
>Unfortunately, MOBY Central has crashed AGAIN this morning so you will
>not be able to register your service there until it is restarted... I
>still have not found the source of these ongoing problems but the
>crashes are getting worse - I can't even log in to that machine
>anymore. If I cannot find the source of these problems by the end of
>the week I will ask everyone to point their code at the mirror of MOBY
>Central that I am running here in Vancouver, since it seems to be more
>stable.
>
>
>
>>>sigh<<
>>>
>>>
>
>Cheers all
>
>M
>
>
>
>
>
>On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
>
>
>>Hi Mark,
>>I say "the Fasta Example Service" which is at the URL:
>>http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
>>I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
>>MobyEd_dispatcher.cgi for HMM search. I have a function for registering
>>service to Moby in the Hmm_test_central.pl.
>>I think when I run Hmm_test_central.pl, them HMM service will be
>>registered in Moby center. But I use the command line to check it, it is
>>not registered. I am not clear about this. Do we get any email from Moby
>>once the service is registered?
>>Anyway, Thank you for the information. I will check the tutorial again.
>>I guess that I may did not correct.
>>
>>Regards,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi Joyce,
>>>
>>>When you say "the Fasta example" which example do you mean? Can you
>>>send the URL?
>>>
>>>To answer your question - on this page:
>>>http://www.biomoby.org/tutorials.html
>>>
>>>there is a tutorial that includes information about how to register your
>>>service in MOBY Central.
>>>
>>>If you don't want to do it through code, there is also a web based GUI
>>>written by Eddie Kawas that will help you register your service - you
>>>can get to it by clicking the appropriate link from the Tools and Toys
>>>page (http://www.biomoby.org/toolstoys.html).
>>>
>>>Unfortunately, MOBY Central has just crashed... badly... and I need
>>>someone to reboot it, but it is on the other side of the continent so it
>>>might take a while until someone notices. As such, you will have to
>>>wait for a while until you will be able to register your service. Sorry
>>>about that! It doesn't happen very often...
>>>
>>>Let me know if you need any more help.
>>>
>>>Cheers!
>>>
>>>Mark
>>>
>>>
>>>
>>>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>>>
>>>
>>>
>>>
>>>>Hi All,
>>>>I am new to Moby. I followed the Fasta example service to create our
>>>>svervice. How do I register our service to Moby Centrol? could Anyone
>>>>let me know about?
>>>>Thanks,
>>>>
>>>>Joyce
>>>>
>>>>Mark Wilkinson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>>>Eddie and with help and advice from Stephen Evanchik at IBM.
>>>>>
>>>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>>>screen for viewing. This is available under the "Cool Tools" link from
>>>>>the MOBY homepage.
>>>>>
>>>>>Cheers all!
>>>>>
>>>>>M
>>>>>
>>>>>(reminder - just one more day to register for the MOBY meeting at a
>>>>>discount rate!!)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev at biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
...on the road!
From smontgom at bcgsc.bc.ca Thu Mar 31 19:01:26 2005
From: smontgom at bcgsc.bc.ca (Stephen Montgomery)
Date: Thu, 31 Mar 2005 16:01:26 -0800
Subject: [MOBY-dev] moby data and parameters
Message-ID: <424C8F56.7080701@bcgsc.bc.ca>
hi -
does anyone have an example of a xml input where more than one dna
sequence is coming down the wire. is this a collection?
also, for a registered return data type we want to attach some
parameters (corresponding to the application that is going to be run).
is there a java example out there of doing this?
all the best,
stephen
ps ben and i had an awesome crash coding session yesterday. set-up the
plan, built the supports, now we just need to execute the vision. rock on.
From octave.noubibou at gsf.de Mon Mar 7 15:52:35 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Mon, 07 Mar 2005 16:52:35 +0100
Subject: [MOBY-dev] java api
In-Reply-To: <200502190736.j1J7aPKr002666@portal.open-bio.org>
References: <200502190736.j1J7aPKr002666@portal.open-bio.org>
Message-ID: <422C78C3.1020003@gsf.de>
Hi all,
as promised in my previous mail(see below), i have attached to this
message my source codes for parsing moby input xml .
The "RetrieveElementWS.java" class is just to show how you can use it.
your comments are welcome
octave
>
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>>as Yan has mentioned, i have joined the PlaNet project at MIPS
>>>>since 3 months now. one of my first tasks was to provide a generic
>>>>API to simplify access to the pameters (queryID, namespace, id)
>>>>one needs from the moby input xml to run the services and also methods
>>>>to generate moby conform xml result.
>>>>
>>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>>purpose.
>>>>At the moment all you need to get your parameters is to use the method
>>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>>This method return a vector of the form e.g.:
>>>>
>>>>(((queryID1,ns,id))) for a simple type
>>>>
>>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>>collection
>>>>
>>>>or
>>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>>for an input with 2 invocations, the first been a collection and the
>>>>second a simple type.
>>>>
>>>>currently i do not handle secondary articles, but this should not be
>>>>difficult.
>>>>
>>>>we habe tried in our java services and everything seems to be ok.
>>>>
>>>>i am commenting the code now. once it is finished, i will like to
>>>>share it with you for comment or rectification and of course use.
>>>>Is there any possibility to upload this in central repository?
>>>>
>>>>best regards
>>>>
>>>>octave
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericInputParser.java
Type: text/x-java
Size: 11797 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GetInputDataForQuery.java
Type: text/x-java
Size: 2581 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GenericMobyOutputwriter.java
Type: text/x-java
Size: 14047 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RetrieveElementWS.java
Type: text/x-java
Size: 6154 bytes
Desc: not available
URL:
From mwilkinson at mrl.ubc.ca Mon Mar 7 17:40:04 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 07 Mar 2005 09:40:04 -0800
Subject: [MOBY-dev] Registration for the May 7/8 BioMOBY meeting in Vancouver
Message-ID: <1110217204.3898.418.camel@mobycentral.icapture.ubc.ca>
Hi all,
I've set up a CGI form for registration. Please submit your
registration ASAP so that I can complete the budget for the meeting. I
will be doing my best to supplement your room and food from my grant so
that your travel will be the primary expense to you.
http://biomoby.org/cgi-bin/register.cgi
Cheers! See you all in Vancouver!
Mark
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 9 00:54:59 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 08 Mar 2005 16:54:59 -0800
Subject: [MOBY-dev] bug fix (??) for collection inputs/outputs
Message-ID: <1110329699.9567.11.camel@mobycentral.icapture.ubc.ca>
I've claimed that before on this bug, but it seems to be an unusually
pesky one! Anyway, the next attempt has just been committed.
I **think** that database entries for collection objects should now,
properly, write a service_instance_id of NULL into the database for
their simple_input/output tables. The problem has been that they have
been writing "0" and this causes them to not show up in the XML service
signature from a findService call.
If you are running your own MOBY Central you will need to update the
database by hand... again... sorry! I thought I had killed this one
months ago, but apparently not.
update simple_input set service_instance_id=NULL where
service_instance_id=0
(same for simple_output)
my apologies again!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Fri Mar 11 21:25:54 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Fri, 11 Mar 2005 22:25:54 +0100
Subject: [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
Message-ID: <42320CE2.3040201@cnb.uam.es>
Hi MOBYfiers!
I think I have found a bug in
MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
nodes. When getNodeContentWithArticle is handling nodes with its content
encapsulated in a CDATA section (for instance, a Blast result, a
sequence with a description, or an XML content), it ignores it. So, any
perl service which uses this function would not be able to get the
content when any MOBY client uses CDATA to maintain the original layout.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Fri Mar 11 22:15:05 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri, 11 Mar 2005 14:15:05 -0800
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <42320CE2.3040201@cnb.uam.es>
References: <42320CE2.3040201@cnb.uam.es>
Message-ID: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Committed a fix - try it now.
M
On Fri, 2005-03-11 at 13:25, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> Hi MOBYfiers!
> I think I have found a bug in
> MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
> nodes. When getNodeContentWithArticle is handling nodes with its content
> encapsulated in a CDATA section (for instance, a Blast result, a
> sequence with a description, or an XML content), it ignores it. So, any
> perl service which uses this function would not be able to get the
> content when any MOBY client uses CDATA to maintain the original layout.
>
> Best Regards,
> Jos?? Mar??a
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Fri Mar 11 22:15:05 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Fri, 11 Mar 2005 14:15:05 -0800
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <42320CE2.3040201@cnb.uam.es>
References: <42320CE2.3040201@cnb.uam.es>
Message-ID: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Committed a fix - try it now.
M
On Fri, 2005-03-11 at 13:25, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> Hi MOBYfiers!
> I think I have found a bug in
> MOBY::CommonSubs::getNodeContentWithArticle, related to CDATA_SECTION
> nodes. When getNodeContentWithArticle is handling nodes with its content
> encapsulated in a CDATA section (for instance, a Blast result, a
> sequence with a description, or an XML content), it ignores it. So, any
> perl service which uses this function would not be able to get the
> content when any MOBY client uses CDATA to maintain the original layout.
>
> Best Regards,
> Jos?? Mar??a
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Mon Mar 14 15:41:13 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 14 Mar 2005 16:41:13 +0100
Subject: [moby] [MOBY-dev] A possible bug in
MOBY::CommonSubs::getNodeContentWithArticle
In-Reply-To: <1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
References: <42320CE2.3040201@cnb.uam.es>
<1110579305.25910.74.camel@mobycentral.icapture.ubc.ca>
Message-ID: <4235B099.402@cnb.uam.es>
Yes, it works!
Thanks, Mark!!
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From jmfernandez at cnb.uam.es Mon Mar 14 15:54:30 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 14 Mar 2005 16:54:30 +0100
Subject: [MOBY-dev] About serviceNotes block
Message-ID: <4235B3B6.7090508@cnb.uam.es>
Hi again, MOBYfiers!
I am exploring the use of the serviceNotes block, and from the BioMOBY
v0.8 documents I have understood that only textual (human readable)
content should go inside it. Would it be a BioMOBY protocol violation if
I use it to send some XML content? I want to use it to communicate some
warnings related to services which answer a collection, and I want to
separate warnings from different answers (I don't want to go back to
flat file world!).
Also, I think I have found a possible bug in the current implementation
of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
getNodeContentWithArticle.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Mon Mar 14 18:55:30 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 14 Mar 2005 10:55:30 -0800
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235B3B6.7090508@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
Message-ID: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 07:54, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> Also, I think I have found a possible bug in the current implementation
> of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
> getNodeContentWithArticle.
fixed. Let me know if it is still a problem.
> Would it be a BioMOBY protocol violation if
> I use it to send some XML content? I want to use it to communicate some
> warnings related to services which answer a collection, and I want to
> separate warnings from different answers (I don't want to go back to
> flat file world!).
to be honest, we haven't thought much about what should/not go into that
block. It was intentionally left ambiguous so that we could discuss it
at some point in the future. It appears that the point has now come!
My gut is that we should not just stick raw XML in there, since that
isn't very MOBYesque... the MOBYesque way would be to make another
ontology :-) A "commentary ontology" or something like that - then wrap
your XML according to its type.
what kinds of information do you have in your XML?
Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
provision information data? Do you have a defined set of predicates for
that?
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Mon Mar 14 18:55:30 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 14 Mar 2005 10:55:30 -0800
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235B3B6.7090508@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
Message-ID: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 07:54, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> Also, I think I have found a possible bug in the current implementation
> of MOBY::CommonSubs::getServiceNotes, like the previous one I told in
> getNodeContentWithArticle.
fixed. Let me know if it is still a problem.
> Would it be a BioMOBY protocol violation if
> I use it to send some XML content? I want to use it to communicate some
> warnings related to services which answer a collection, and I want to
> separate warnings from different answers (I don't want to go back to
> flat file world!).
to be honest, we haven't thought much about what should/not go into that
block. It was intentionally left ambiguous so that we could discuss it
at some point in the future. It appears that the point has now come!
My gut is that we should not just stick raw XML in there, since that
isn't very MOBYesque... the MOBYesque way would be to make another
ontology :-) A "commentary ontology" or something like that - then wrap
your XML according to its type.
what kinds of information do you have in your XML?
Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
provision information data? Do you have a defined set of predicates for
that?
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Mon Mar 14 21:03:38 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Mon, 14 Mar 2005 22:03:38 +0100
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
Message-ID: <4235FC2A.9030807@cnb.uam.es>
>
> fixed. Let me know if it is still a problem.
>
Okay, getServiceNotes works with CDATA.
> what kinds of information do you have in your XML?
>
Well, something like the next one. This is an example from INB
(http://www.inab.org) guys, which are stretching BioMOBY to its limits.
You should note they are using a different namespace, so they are
avoiding past, present and future XML tag collisions:
incomplete_outputIntAct DB engine was not
available
Looking at the example, the structure is describing that answer with
queryID 'b2' could be incomplete because some of the used databases was
not available at runtime. INB prefers serviceNotes block instead of
ProvisionInformation block because most of the warnings, and in general,
exception information, comprise the whole output, which is a Collection
for some services.
The other drawback for ProvisionInformation is that it cannot appear in
a mobyData outside any object, or even Simple or Collection
declarations, so it becomes useless when you want (or need) to notify
some information related to a Collection, or there is no answer at all
because there was a problem with that query.
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Mon Mar 14 21:27:29 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Mon, 14 Mar 2005 13:27:29 -0800
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <4235FC2A.9030807@cnb.uam.es>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
<4235FC2A.9030807@cnb.uam.es>
Message-ID: <1110835649.29060.127.camel@mobycentral.icapture.ubc.ca>
On Mon, 2005-03-14 at 13:03, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> INB prefers serviceNotes block instead of
> ProvisionInformation block because most of the warnings, and in general,
> exception information, comprise the whole output, which is a Collection
> for some services.
That's an interesting observation - I hadn't thought about that. The
reason for the ProvisionInformation block being a part of an object was
so that different subcomponents of a complex object could potentially
have different provision annotations... however you rightly point out
that this would all have to be duplicated if these were part of a
collection, and that it would be more efficient to have it at that
level.
The serviceNotes block is the place where I had intended for this
"global" type of information to be placed - we just need to agree on a
format.
> The other drawback for ProvisionInformation is that it cannot appear in
> a mobyData outside any object, or even Simple or Collection
> declarations, so it becomes useless when you want (or need) to notify
> some information related to a Collection,
I like the provision information block where it is for the reasons I
indicate above, but I tend to agree with you that there is possibly a
need for one additional level of provider feedback (I have to point out,
however, that as far as I know you and I are the only people who are
using these extra parts of the MOBY message ;-) )
> or there is no answer at all
> because there was a problem with that query.
It was intended that a blank mobyData node would indicate a "problem",
but it is not possible to differentiate between a problematic query, and
the lack of an answer to a valid query at this level. Since the whole
MOBY thing is intended to be accessed by machines, we would have had to
build (or re-build) a large vocabulary of possible error messages in
order to create a machine-readable solution to errors at this level of
resolution... and since we cannot reasonably predict all of the possible
errors to the level of resolution required for a machine to fix the
problem on its own, this seemed a bit futile... so I didn't bother.
A blank mobyData block means "I don't know what you are talking about" -
for whatever reason; it may be, but it is not necessarily an error.
This is something we could re-visit at the next MOBY meeting, however.
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 00:09:37 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Tue, 15 Mar 2005 16:09:37 -0800
Subject: [MOBY-dev] REGISATRATION CALL #2 MOBY-DIC meeting
Message-ID: <1110931777.3201.18.camel@mobycentral.icapture.ubc.ca>
Hi all,
Just re-pinging everyone who wants to come to Vancouver for the MOBY DIC
meeting in May (7/8). PLEASE REGISTER AS SOON AS POSSIBLE at:
http://www.biomoby.org/cgi-bin/register.cgi
I am pretty sure now that I will be able to cover 100% of your housing
costs, and probably some of the meal costs as well. I'm still working
out the final budget, but I do need to know how many people are coming
before I can come up with the final number.
My current guesstimate is that the registration fees (to cover your room
for up to three nights, and breakfast + lunch on the two meeting days)
will be about CAD$200. I will try to bring that even lower if I can!
Cheers!
Mark
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From jmfernandez at cnb.uam.es Wed Mar 16 14:01:35 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 16 Mar 2005 15:01:35 +0100
Subject: [MOBY-dev] Some Perl warnings in registerService with secondaries
Message-ID: <42383C3F.9070102@cnb.uam.es>
Hi MOBYfiers!
after some tests with registerService and a service definition with
secondaries, I have realized that you have to declare an empty list of
enums in each secondary parameter, so the method registers your service.
Also, even when a secondary parameter does not have minimum, maximum or
default value, the method uses it internally, and so the warnings are
ocurring.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 946.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 948.
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 949.
As I have seen inside the code, it seems registerService submits all
these fields to MOBY Central, even when they have not been declared.
But, it should not do it... Is it perhaps a bug?
Best Regards,
Jos? Mar?a
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From markw at illuminae.com Wed Mar 16 15:42:42 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 16 Mar 2005 09:42:42 -0600
Subject: [unclassified] [MOBY-dev] Some Perl warnings in registerService
with secondaries
In-Reply-To: <42383C3F.9070102@cnb.uam.es>
References: <42383C3F.9070102@cnb.uam.es>
Message-ID: <423853F2.2040307@illuminae.com>
Hi Jos?,
Thanks for the bug report! I'm glad someone else is using the secondary
parameter code - up to now, I think only our friends at the Pasteur
institute were using them, but the more eyes/fingers we have testing
these the better!
Could you please do a CVS update so that your error messages line up
with the current codebase? that will make it easier to debug. e.g. in
my copy of the code, line 948 is blank, so it should not be throwing the
error you indicate below.
I will continue exploring the problem until I hear back from you.
Cheers!
M
Jos? Mar?a Fern?ndez Gonz?lez wrote:
> Hi MOBYfiers!
> after some tests with registerService and a service definition
> with secondaries, I have realized that you have to declare an empty
> list of enums in each secondary parameter, so the method registers
> your service. Also, even when a secondary parameter does not have
> minimum, maximum or default value, the method uses it internally, and
> so the warnings are ocurring.
>
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 946.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 948.
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/vendor_perl/5.8.5/MOBY/Client/Central.pm line 949.
>
> As I have seen inside the code, it seems registerService submits
> all these fields to MOBY Central, even when they have not been
> declared. But, it should not do it... Is it perhaps a bug?
>
> Best Regards,
> Jos? Mar?a
From jmfernandez at cnb.uam.es Wed Mar 16 16:15:22 2005
From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=)
Date: Wed, 16 Mar 2005 17:15:22 +0100
Subject: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <423853F2.2040307@illuminae.com>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
Message-ID: <42385B9A.9070803@cnb.uam.es>
Hi Mark,
I have made a cvs update -dP and my moby-live copy was already
up-to-date. I am using the default branch and server
(cvs at cvs.open-bio.org:/home/repository/moby). Are you talking about
another different branch/server?
Cheers,
Jos? Mar?a
Mark Wilkinson wrote:
> Hi Jos?,
>
> Thanks for the bug report! I'm glad someone else is using the secondary
> parameter code - up to now, I think only our friends at the Pasteur
> institute were using them, but the more eyes/fingers we have testing
> these the better!
>
> Could you please do a CVS update so that your error messages line up
> with the current codebase? that will make it easier to debug. e.g. in
> my copy of the code, line 948 is blank, so it should not be throwing the
> error you indicate below.
>
> I will continue exploring the problem until I hear back from you.
>
> Cheers!
>
> M
>
>
--
Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es
Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06
Grupo de Dise?o de Proteinas Protein Design Group
Centro Nacional de Biotecnolog?a National Center of Biotechnology
C.P.: 28049 Zip Code: 28049
C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain)
From mwilkinson at mrl.ubc.ca Wed Mar 16 18:11:38 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 10:11:38 -0800
Subject: [moby] Re: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <42385B9A.9070803@cnb.uam.es>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
<42385B9A.9070803@cnb.uam.es>
Message-ID: <1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
hmmmmm.... I think I am working on HEAD. I just did a fresh checkout
and I still get the lines you indicate as either blank or commented-out
in that copy as well.
??
Anyway, I will try to reproduce the problem first, and if I can
reproduce it, I'll debug it and commit the changes to HEAD. Then we
should see if you are able to update these into your version.
Cheers!
M
On Wed, 2005-03-16 at 08:15, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> Hi Mark,
> I have made a cvs update -dP and my moby-live copy was already
> up-to-date. I am using the default branch and server
> (cvs at cvs.open-bio.org:/home/repository/moby). Are you talking about
> another different branch/server?
>
> Cheers,
> Jos?? Mar??a
>
> Mark Wilkinson wrote:
> > Hi Jos??,
> >
> > Thanks for the bug report! I'm glad someone else is using the secondary
> > parameter code - up to now, I think only our friends at the Pasteur
> > institute were using them, but the more eyes/fingers we have testing
> > these the better!
> >
> > Could you please do a CVS update so that your error messages line up
> > with the current codebase? that will make it easier to debug. e.g. in
> > my copy of the code, line 948 is blank, so it should not be throwing the
> > error you indicate below.
> >
> > I will continue exploring the problem until I hear back from you.
> >
> > Cheers!
> >
> > M
> >
> >
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 18:18:13 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 10:18:13 -0800
Subject: [moby] Re: [unclassified] [MOBY-dev] Some Perl warnings in
registerServicewith secondaries
In-Reply-To: <1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
References: <42383C3F.9070102@cnb.uam.es> <423853F2.2040307@illuminae.com>
<42385B9A.9070803@cnb.uam.es>
<1110996698.6585.24.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110997093.6585.26.camel@mobycentral.icapture.ubc.ca>
D'OH!
Me being stupid (actually, my editor being stupid, but me not noticing)
We're working on the same code, and I can replicate your error.
Fixing it now...
M
On Wed, 2005-03-16 at 10:11, Mark Wilkinson wrote:
> hmmmmm.... I think I am working on HEAD. I just did a fresh checkout
> and I still get the lines you indicate as either blank or commented-out
> in that copy as well.
>
> ??
>
> Anyway, I will try to reproduce the problem first, and if I can
> reproduce it, I'll debug it and commit the changes to HEAD. Then we
> should see if you are able to update these into your version.
>
> Cheers!
>
> M
>
>
> On Wed, 2005-03-16 at 08:15, Jos?? Mar??a Fern??ndez Gonz??lez wrote:
> > Hi Mark,
> > I have made a cvs update -dP and my moby-live copy was already
> > up-to-date. I am using the default branch and server
> > (cvs at cvs.open-bio.org:/home/repository/moby). Are you talking about
> > another different branch/server?
> >
> > Cheers,
> > Jos?? Mar??a
> >
> > Mark Wilkinson wrote:
> > > Hi Jos??,
> > >
> > > Thanks for the bug report! I'm glad someone else is using the secondary
> > > parameter code - up to now, I think only our friends at the Pasteur
> > > institute were using them, but the more eyes/fingers we have testing
> > > these the better!
> > >
> > > Could you please do a CVS update so that your error messages line up
> > > with the current codebase? that will make it easier to debug. e.g. in
> > > my copy of the code, line 948 is blank, so it should not be throwing the
> > > error you indicate below.
> > >
> > > I will continue exploring the problem until I hear back from you.
> > >
> > > Cheers!
> > >
> > > M
> > >
> > >
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 19:02:44 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 11:02:44 -0800
Subject: [MOBY-dev] My bad! database strucural change needed.
Message-ID: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
To everyone running a local MOBY Central:
We need to update the table structure for MOBY Central in light of the
bug fix for Jose's reported bug this morning. Sorry everyone!
mysql> alter table secondary_input modify datatype varchar(20);
It was not recording secondary datatypes properly. There was only one
instance of an incorrect record in the public registry database and I
was able to fix that one by hand. Hopefully it should be similarly
simple for everyone else.
I'm committing the code changes to the CVS right now.
what colour is MY red face?! :-)
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 19:05:01 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 11:05:01 -0800
Subject: [MOBY-dev] NIX THAT was Re: My bad! database strucural change
needed.
In-Reply-To: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
References: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
NIX THAT LAST MESSAGE - it was the test instance of MOBY Central that
was defective, the production instance is correct.
...>>sigh<<.... bad day for debugging...
M
On Wed, 2005-03-16 at 11:02, Mark Wilkinson wrote:
> To everyone running a local MOBY Central:
>
> We need to update the table structure for MOBY Central in light of the
> bug fix for Jose's reported bug this morning. Sorry everyone!
>
> mysql> alter table secondary_input modify datatype varchar(20);
>
> It was not recording secondary datatypes properly. There was only one
> instance of an incorrect record in the public registry database and I
> was able to fix that one by hand. Hopefully it should be similarly
> simple for everyone else.
>
> I'm committing the code changes to the CVS right now.
>
> what colour is MY red face?! :-)
>
> M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 16 19:05:01 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 16 Mar 2005 11:05:01 -0800
Subject: [MOBY-dev] NIX THAT was Re: My bad! database strucural change
needed.
In-Reply-To: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
References: <1110999764.6880.7.camel@mobycentral.icapture.ubc.ca>
Message-ID: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
NIX THAT LAST MESSAGE - it was the test instance of MOBY Central that
was defective, the production instance is correct.
...>>sigh<<.... bad day for debugging...
M
On Wed, 2005-03-16 at 11:02, Mark Wilkinson wrote:
> To everyone running a local MOBY Central:
>
> We need to update the table structure for MOBY Central in light of the
> bug fix for Jose's reported bug this morning. Sorry everyone!
>
> mysql> alter table secondary_input modify datatype varchar(20);
>
> It was not recording secondary datatypes properly. There was only one
> instance of an incorrect record in the public registry database and I
> was able to fix that one by hand. Hopefully it should be similarly
> simple for everyone else.
>
> I'm committing the code changes to the CVS right now.
>
> what colour is MY red face?! :-)
>
> M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From edward.kawas at gmail.com Wed Mar 16 20:18:01 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed, 16 Mar 2005 12:18:01 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Hi,
I was wondering if people could let me know what version of
Java people are using. I was hoping to see if we could
somehow push everyone towards using 1.5 in the near future.
I know the upgrade isn't trivial, so I was hoping to hear
your comments.
Thanks,
Eddie
From edward.kawas at gmail.com Wed Mar 16 20:18:01 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Wed, 16 Mar 2005 12:18:01 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <1110999901.6880.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Hi,
I was wondering if people could let me know what version of
Java people are using. I was hoping to see if we could
somehow push everyone towards using 1.5 in the near future.
I know the upgrade isn't trivial, so I was hoping to hear
your comments.
Thanks,
Eddie
From bmg at sfu.ca Wed Mar 16 20:48:20 2005
From: bmg at sfu.ca (Benjamin Good)
Date: Wed, 16 Mar 2005 12:48:20 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <42389B94.3070106@sfu.ca>
Happy to move on to 1.5, would be helpful for some of the things I'm doing.
-Ben
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
From gordonp at ucalgary.ca Wed Mar 16 21:11:33 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 16 Mar 2005 14:11:33 -0700
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389B94.3070106@sfu.ca>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
<42389B94.3070106@sfu.ca>
Message-ID: <4238A105.2050701@ucalgary.ca>
I haven't played around with 1.5 much yet, as I haven't needed its new
features (I'm using 1.4.2). I think that if the existing MOBY code
works fine in 1.5, we should move forward and let people use Generics,
etc. in the codebase. Better to do this transition before even more
people are developing code...
Benjamin Good wrote:
> Happy to move on to 1.5, would be helpful for some of the things I'm
> doing.
>
> -Ben
>
> Eddie Kawas wrote:
>
>> Hi,
>>
>> I was wondering if people could let me know what version of
>> Java people are using. I was hoping to see if we could
>> somehow push everyone towards using 1.5 in the near future.
>> I know the upgrade isn't trivial, so I was hoping to hear
>> your comments.
>>
>> Thanks,
>>
>> Eddie
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
>>
>>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>
From ywong at infobiogen.fr Thu Mar 17 09:03:41 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Thu, 17 Mar 2005 10:03:41 +0100
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <423947ED.9090103@infobiogen.fr>
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
java 1.4.2 and java 1.5
From octave.noubibou at gsf.de Thu Mar 17 10:12:44 2005
From: octave.noubibou at gsf.de (Octave Noubibou)
Date: Thu, 17 Mar 2005 11:12:44 +0100
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID: <4239581C.9030909@gsf.de>
Eddie Kawas wrote:
>Hi,
>
>I was wondering if people could let me know what version of
>Java people are using. I was hoping to see if we could
>somehow push everyone towards using 1.5 in the near future.
>I know the upgrade isn't trivial, so I was hoping to hear
>your comments.
>
>Thanks,
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
hi Eddie,
currently, we are using 1.4.2. i hoppe it should not be a big problem to
move to 1.5 if needed.
octave
From tmo at ebi.ac.uk Thu Mar 17 13:13:48 2005
From: tmo at ebi.ac.uk (Tom Oinn)
Date: Thu, 17 Mar 2005 13:13:48 +0000
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <4239581C.9030909@gsf.de>
References: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
<4239581C.9030909@gsf.de>
Message-ID: <4239828C.2070602@ebi.ac.uk>
Octave Noubibou wrote:
> Eddie Kawas wrote:
>
>> Hi,
>>
>> I was wondering if people could let me know what version of
>> Java people are using. I was hoping to see if we could
>> somehow push everyone towards using 1.5 in the near future.
>> I know the upgrade isn't trivial, so I was hoping to hear
>> your comments.
Highly non trivial, are you using Axis? We've pretty much given up on
1.5 until the axis devs get their act together as right now it won't
work. We're using 1.4.2_07 for Taverna
Cheers,
Tom
From senger at ebi.ac.uk Mon Mar 21 14:44:31 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Mon, 21 Mar 2005 14:44:31 +0000 (GMT)
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To: <42389479.250e8d57.7abc.6e0c@mx.gmail.com>
Message-ID:
> I was wondering if people could let me know what version of
> Java people are using. I was hoping to see if we could
> somehow push everyone towards using 1.5 in the near future.
>
There will never be a single date when people can stop using the old
version and start to use the new version. Therefore, there should be
some "transitional rules" to follow. The rules must be both for
the compilation and run-time. Here is how it perhaps can work:
a) The run-time is completely up to the code developer. If [s]he
insists (needs) to use newer Java 1.5 his/her code should be written in a
way that it throws an exception if run under older JVM.
b) The compilation time can be solved by having Java version checks in
Ant. Ant is prepared for it, and I can make it into jMoby build.xml. So if
you have a code, that you wish to commit to jMoby and this code requires
1.5. please send it first to me and I will make the changes in build.xml.
b1) There may be other targets in Ant (other than compilation) that
depend on Java version - such as deploying web services under Axis (as
pointed out Tom). I can also help with version checking for such targets
if you let me know (at the moment there is no such target in build.xml).
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From edward.kawas at gmail.com Mon Mar 21 17:01:44 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Mon, 21 Mar 2005 09:01:44 -0800
Subject: [MOBY-dev] Java packages conversation
Message-ID: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Hi,
Martin & I thought that our conversation might interest
others in the list, so here it is:
------------Eddie-------------------
Hi,
I have been trying to think of a package hierarchy that
would be useful for jMoby now and in the future. I have come
up with the following draft, and was hoping for criticism.
Below you will find the package structure I think might
work:
#######################
org.biomoby.central.
registry.
retrieval.
_to_be_named_later.
register
deregister
client.
perlConverts.
execution.
invocation
ui.
commandline.
graphical.
swing
applets
servlets.
lsid
jResource
plugins.
taverna
dom.
testing.
###########################
Anything that you think is missing? I hope to be able to
slot the current classes into these packages a little at a
time.
In the package perlConverts I was hoping to slot in java
versions of Perl scripts that have been already created,
like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
cgi-bin/types/Namespaces.
In the package dom, I thought that people may be comfortable
with a particular version of dom (w3c.dom, jDom, etc) and so
I thought it might be nice to separate implementations.
I think that the rest of the hierarchy is pretty straight
forward and doesn't need explanation, although I could be
wrong.
Also, I do not have as much knowledge about Moby as many of
you do and I may have missed some obvious things, so please
let me know.
Thanks,
Eddie Kawas
------------Martin----------------
Thanks for the overview.
I have just a few questions:
1) Does the new proposal require changes in the current
(existing) packages? If yes, in which?
2) Are you going to create package 'slots' now - and only
later to populate them, or are you proposing to create them
only when you have something to be there?
3) perlConverts: I do not feel comfortable with this
name. Do users need to know (from the package name) the
reason why a package was created?
I think that better is to name a package by its
functionality, not by the origin. But again, I would perhaps
let people to create their package names in a less
structured (less detailed) way than you are proposing (which
I will explain when I have answers for the two previous
questions)
- so if somebody wants to keep te origin in the package
name, I am not basically against it. Let's return to these
comments later.
4)
> In the package dom, I thought that people may be
comfortable with a
> particular version of dom (w3c.dom, jDom, etc) and so I
thought it
> might be nice to separate implementations.
>
Again, I think that this details should be (if one wants
to have several separate implementations) *below* package
where a dom is used. You ut it under 'client' - but what if
I need to use a dom in a class belonging to a registry
package, or to a commandLine package? The 'dom'
name should be there - in more than one place.
> I think that the rest of the hierarchy is pretty straight
forward and
> doesn't need explanation, although I could be wrong.
>
5)
Well, if you publish rules you need to explain them
anyway. So why not to do it now :-) It would be good to have
few lines defineg what should go into individual packages.
Cheers,
Martin
-------------Eddie--------------
> 1) Does the new proposal require changes in the current
> (existing)
> packages? If yes, in which?
Yes, however, I am not sure which classes will be moved
where. I tried to see what classes we had and then I tried
to create a slot that it might fit into.
> 2) Are you going to create package 'slots' now - and
only later to
> populate them, or are you proposing to create them only
when you have
> something to be there?
I was thinking of creating them now. Is this a bad idea?
> 3) perlConverts: I do not feel comfortable with this
name.
I agree. I think I did that out of sheer laziness.
> 4)
> > In the package dom ...
You are right, this should be below a package when DOM is
used, not in client.
Thanks,
Eddie
------------Martin----------------
> > 1) Does the new proposal require changes in the
current
> > (existing)
> > packages? If yes, in which?
> Yes, however, I am not sure which classes will be moved
where.
>
Well, I am reluctant to make these changes - at least in
the code written (mainly) by me - unless there is a good
reason for that. Changes in package names (in existing code)
are evil - if the code is already used by others. Sorry for
that...
> > 2) Are you going to create package 'slots' now - and
only later
> > to populate them, or are you proposing to create them
only when you
> > have something to be there?
> I was thinking of creating them now. Is this a bad idea?
>
I always liked such idea - but (in my experiences) it
simply never worked (unless you are in a strict industrial
environment). Therefore, I suggest to live with a compromise
- to "dictate" only relatively high-level package names, and
let people to create their own below.
Therefore, I have started only with
org.biomoby.[client|shared|registry] - and we need possibly
something for support for service providers (I am using now
org.biomoby.service - but there are only some testing
classes now).
Having said that, I think it is a good idea to write a
document - and to publish it on the jMoby pages - that would
suggest what package names (below the ones I mentioned
above) could be used for specific purposes.
But not to create them in advance, and not to enforce it
later. Just like hints. As always with hints, people will
follow them if the hints are well explained and known to
people.
Let me know if you are uncomfortable with the high-level
package names as they exist now - and let's discuss what to
do with them. BTW, your
proposal:
org.biomoby.central.
registry.
retrieval.
_to_be_named_later.
register
deregister
cannot work easily. Simply because it is too detailed. There
may be classes (such as CentralImpl) that work cross the
packages you defined.
No, I would definitely keep this part simpler - just
org.biomoby.registry.
(But this was just an example, let's discuss it.)
Cheers,
Martin
--------------Eddie---------------
So you don't think that we should try and create a more
detailed hierarchy. I thought that one would be nice,
because we were stumbling upon users that had created almost
duplicate code to that which was in jMoby. Ultimately, I was
hoping to reduce code duplication in order to get people
more on their way to doing useful things.
I realize that changing package names is going to be messy,
so we were proposing to do it slowly, maybe a package at a
time with advance warnings. We could have even tried
automating it with scripts that contain the mappings of
where current classes are and where they would be after the
'refactor'-ing.
What do you think?
Eddie
PS: I am all for creating a document that outlines what
should be placed where, etc.
------------Martin----------------
> I thought that one would be nice, because we were
stumbling upon users
> that had created almost duplicate code to that which was
in jMoby.
>
This is obviously bad and we should perhaps contact these
people and try to convince them to re-use existing code (I
am working now, for example, with Sophie Durand
to convince her to re-use some
exiting code for her classes). But I believe that changing
package names will not help to achieve it. We need different
ways to convince them.
> We could have even tried automating it with scripts that
contain the
> mappings of where current classes are and where they would
be after
> the 'refactor'-ing.
>
I agree that it would be useful to provide a refactoring
tool - if we need to refactor. But, as I said, I do not
think that refactoring will help us now.
Sorry for not agreeing with you on the package name
changes. But I still believe that providing hints how to
name their code would be very helpful.
Martin
PS. Btw, feel free to reproduce our conversation on the
biomoby-dev list if you wish. M.
--
Martin Senger
-----------Eddie-------------
Thanks for your comments, I think that I should rethink this
whole issue and then get back to you.
Eddie
From edward.kawas at gmail.com Mon Mar 21 17:14:34 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Mon, 21 Mar 2005 09:14:34 -0800
Subject: [MOBY-dev] What versions of JAVA is everyone using?
In-Reply-To:
Message-ID: <423f00fb.14d19c85.67e0.0ec1@mx.gmail.com>
Martin,
May I ask you what it was you thought would be placed in the
packages client, shared, and registry when you created them?
Thanks,
Eddie
> -----Original Message-----
> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
> dev-bounces at portal.open-bio.org] On Behalf Of Martin
> Senger
> Sent: Monday, March 21, 2005 6:45 AM
> To: Core developer announcements
> Subject: Re: [MOBY-dev] What versions of JAVA is everyone
> using?
>
> > I was wondering if people could let me know what version
> of
> > Java people are using. I was hoping to see if we could
> > somehow push everyone towards using 1.5 in the near
> future.
> >
> There will never be a single date when people can stop
> using the old
> version and start to use the new version. Therefore, there
> should be
> some "transitional rules" to follow. The rules must be
> both for
> the compilation and run-time. Here is how it perhaps can
> work:
>
> a) The run-time is completely up to the code developer.
> If [s]he
> insists (needs) to use newer Java 1.5 his/her code should
> be written in a
> way that it throws an exception if run under older JVM.
>
> b) The compilation time can be solved by having Java
> version checks in
> Ant. Ant is prepared for it, and I can make it into jMoby
> build.xml. So if
> you have a code, that you wish to commit to jMoby and this
> code requires
> 1.5. please send it first to me and I will make the
> changes in build.xml.
>
> b1) There may be other targets in Ant (other than
> compilation) that
> depend on Java version - such as deploying web services
> under Axis (as
> pointed out Tom). I can also help with version checking
> for such targets
> if you let me know (at the moment there is no such target
> in build.xml).
>
> Cheers,
> Martin
>
> --
> Martin Senger
>
> EMBL Outstation - Hinxton Senger at EBI.ac.uk
> European Bioinformatics Institute Phone: (+44) 1223
> 494636
> Wellcome Trust Genome Campus (Switchboard:
> 494444)
> Hinxton Fax : (+44) 1223
> 494468
> Cambridge CB10 1SD
> United Kingdom
> http://industry.ebi.ac.uk/~senger
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
From gordonp at ucalgary.ca Mon Mar 21 17:35:10 2005
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon, 21 Mar 2005 10:35:10 -0700
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
References: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Message-ID: <423F05CE.1060801@ucalgary.ca>
Hi Eddie,
A couple of thoughts:
-What about the data templates and instances? Is org.biomoby.shared
going away? Should there be a org.biomoby.data instead?
-Where should server side or combines server/client objects (e.g.
MobyRequest) go?
>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
> client.
> perlConverts.
> execution.
> invocation
> ui.
> commandline.
> graphical.
> swing
> applets
> servlets.
> lsid
> jResource
> plugins.
> taverna
> dom.
> testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong.
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
> Thanks for the overview.
> I have just a few questions:
>
> 1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
> 2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
> 3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
> 4)
>
>
>>In the package dom, I thought that people may be
>>
>>
>comfortable with a
>
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>
>>
>thought it
>
>
>>might be nice to separate implementations.
>>
>>
>>
> Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom'
>name should be there - in more than one place.
>
>
>
>>I think that the rest of the hierarchy is pretty straight
>>
>>
>forward and
>
>
>>doesn't need explanation, although I could be wrong.
>>
>>
>>
> 5)
> Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
> Cheers,
> Martin
>
>-------------Eddie--------------
>
>
>
>> 1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>
>
>> 2) Are you going to create package 'slots' now - and
>>
>>
>only later to
>
>
>>populate them, or are you proposing to create them only
>>
>>
>when you have
>
>
>>something to be there?
>>
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>
>
>> 3) perlConverts: I do not feel comfortable with this
>>
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>
>
>> 4)
>>
>>
>>>In the package dom ...
>>>
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>
>
>>> 1) Does the new proposal require changes in the
>>>
>>>
>current
>
>
>>>(existing)
>>>packages? If yes, in which?
>>>
>>>
>>Yes, however, I am not sure which classes will be moved
>>
>>
>where.
>
>
> Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>
>
>>> 2) Are you going to create package 'slots' now - and
>>>
>>>
>only later
>
>
>>>to populate them, or are you proposing to create them
>>>
>>>
>only when you
>
>
>>>have something to be there?
>>>
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>
>>
> I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
> Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
> Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined.
>No, I would definitely keep this part simpler - just
>org.biomoby.registry.
>(But this was just an example, let's discuss it.)
>
> Cheers,
> Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>
>
>>I thought that one would be nice, because we were
>>
>>
>stumbling upon users
>
>
>>that had created almost duplicate code to that which was
>>
>>
>in jMoby.
>
>
> This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>
>
>>We could have even tried automating it with scripts that
>>
>>
>contain the
>
>
>>mappings of where current classes are and where they would
>>
>>
>be after
>
>
>>the 'refactor'-ing.
>>
>>
>>
> I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
>
> Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
> Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
>
From ywong at infobiogen.fr Tue Mar 22 08:46:10 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Tue, 22 Mar 2005 09:46:10 +0100
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
References: <423efdfa.606eba4c.671a.0933@mx.gmail.com>
Message-ID: <423FDB52.1000603@infobiogen.fr>
Eddie Kawas wrote:
>Hi,
>
>Martin & I thought that our conversation might interest
>others in the list, so here it is:
>
>------------Eddie-------------------
>
>Hi,
>
>I have been trying to think of a package hierarchy that
>would be useful for jMoby now and in the future. I have come
>up with the following draft, and was hoping for criticism.
>
>Below you will find the package structure I think might
>work:
>
>#######################
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
> client.
> perlConverts.
> execution.
> invocation
> ui.
> commandline.
> graphical.
> swing
> applets
> servlets.
> lsid
> jResource
> plugins.
> taverna
> dom.
> testing.
>###########################
>
>Anything that you think is missing? I hope to be able to
>slot the current classes into these packages a little at a
>time.
>
>In the package perlConverts I was hoping to slot in java
>versions of Perl scripts that have been already created,
>like the cgi-bin/types/Objects ,cgi-bin/types/Services, and
>cgi-bin/types/Namespaces.
>
>In the package dom, I thought that people may be comfortable
>with a particular version of dom (w3c.dom, jDom, etc) and so
>I thought it might be nice to separate implementations.
>
>I think that the rest of the hierarchy is pretty straight
>forward and doesn't need explanation, although I could be
>wrong.
>
>Also, I do not have as much knowledge about Moby as many of
>you do and I may have missed some obvious things, so please
>let me know.
>
>Thanks,
>
>Eddie Kawas
>
>------------Martin----------------
>
> Thanks for the overview.
> I have just a few questions:
>
> 1) Does the new proposal require changes in the current
>(existing) packages? If yes, in which?
>
> 2) Are you going to create package 'slots' now - and only
>later to populate them, or are you proposing to create them
>only when you have something to be there?
>
> 3) perlConverts: I do not feel comfortable with this
>name. Do users need to know (from the package name) the
>reason why a package was created?
>I think that better is to name a package by its
>functionality, not by the origin. But again, I would perhaps
>let people to create their package names in a less
>structured (less detailed) way than you are proposing (which
>I will explain when I have answers for the two previous
>questions)
>- so if somebody wants to keep te origin in the package
>name, I am not basically against it. Let's return to these
>comments later.
>
> 4)
>
>
>>In the package dom, I thought that people may be
>>
>>
>comfortable with a
>
>
>>particular version of dom (w3c.dom, jDom, etc) and so I
>>
>>
>thought it
>
>
>>might be nice to separate implementations.
>>
>>
>>
> Again, I think that this details should be (if one wants
>to have several separate implementations) *below* package
>where a dom is used. You ut it under 'client' - but what if
>I need to use a dom in a class belonging to a registry
>package, or to a commandLine package? The 'dom'
>name should be there - in more than one place.
>
>
>
>>I think that the rest of the hierarchy is pretty straight
>>
>>
>forward and
>
>
>>doesn't need explanation, although I could be wrong.
>>
>>
>>
> 5)
> Well, if you publish rules you need to explain them
>anyway. So why not to do it now :-) It would be good to have
>few lines defineg what should go into individual packages.
>
> Cheers,
> Martin
>
>-------------Eddie--------------
>
>
>
>> 1) Does the new proposal require changes in the current
>>(existing)
>>packages? If yes, in which?
>>
>>
>Yes, however, I am not sure which classes will be moved
>where. I tried to see what classes we had and then I tried
>to create a slot that it might fit into.
>
>
>
>
>> 2) Are you going to create package 'slots' now - and
>>
>>
>only later to
>
>
>>populate them, or are you proposing to create them only
>>
>>
>when you have
>
>
>>something to be there?
>>
>>
>I was thinking of creating them now. Is this a bad idea?
>
>
>
>
>> 3) perlConverts: I do not feel comfortable with this
>>
>>
>name.
>I agree. I think I did that out of sheer laziness.
>
>
>
>
>> 4)
>>
>>
>>>In the package dom ...
>>>
>>>
>You are right, this should be below a package when DOM is
>used, not in client.
>
>Thanks,
>
>Eddie
>
>
>------------Martin----------------
>
>
>
>>> 1) Does the new proposal require changes in the
>>>
>>>
>current
>
>
>>>(existing)
>>>packages? If yes, in which?
>>>
>>>
>>Yes, however, I am not sure which classes will be moved
>>
>>
>where.
>
>
> Well, I am reluctant to make these changes - at least in
>the code written (mainly) by me - unless there is a good
>reason for that. Changes in package names (in existing code)
>are evil - if the code is already used by others. Sorry for
>that...
>
>
>
>>> 2) Are you going to create package 'slots' now - and
>>>
>>>
>only later
>
>
>>>to populate them, or are you proposing to create them
>>>
>>>
>only when you
>
>
>>>have something to be there?
>>>
>>>
>>I was thinking of creating them now. Is this a bad idea?
>>
>>
>>
> I always liked such idea - but (in my experiences) it
>simply never worked (unless you are in a strict industrial
>environment). Therefore, I suggest to live with a compromise
>- to "dictate" only relatively high-level package names, and
>let people to create their own below.
>Therefore, I have started only with
>org.biomoby.[client|shared|registry] - and we need possibly
>something for support for service providers (I am using now
>org.biomoby.service - but there are only some testing
>classes now).
> Having said that, I think it is a good idea to write a
>document - and to publish it on the jMoby pages - that would
>suggest what package names (below the ones I mentioned
>above) could be used for specific purposes.
>But not to create them in advance, and not to enforce it
>later. Just like hints. As always with hints, people will
>follow them if the hints are well explained and known to
>people.
>
> Let me know if you are uncomfortable with the high-level
>package names as they exist now - and let's discuss what to
>do with them. BTW, your
>proposal:
>
>org.biomoby.central.
> registry.
> retrieval.
> _to_be_named_later.
> register
> deregister
>
>cannot work easily. Simply because it is too detailed. There
>may be classes (such as CentralImpl) that work cross the
>packages you defined.
>No, I would definitely keep this part simpler - just
>org.biomoby.registry.
>(But this was just an example, let's discuss it.)
>
> Cheers,
> Martin
>
>--------------Eddie---------------
>
>So you don't think that we should try and create a more
>detailed hierarchy. I thought that one would be nice,
>because we were stumbling upon users that had created almost
>duplicate code to that which was in jMoby. Ultimately, I was
>hoping to reduce code duplication in order to get people
>more on their way to doing useful things.
>
>I realize that changing package names is going to be messy,
>so we were proposing to do it slowly, maybe a package at a
>time with advance warnings. We could have even tried
>automating it with scripts that contain the mappings of
>where current classes are and where they would be after the
>'refactor'-ing.
>
>What do you think?
>
>Eddie
>
>PS: I am all for creating a document that outlines what
>should be placed where, etc.
>
>------------Martin----------------
>
>
>
>>I thought that one would be nice, because we were
>>
>>
>stumbling upon users
>
>
>>that had created almost duplicate code to that which was
>>
>>
>in jMoby.
>
>
> This is obviously bad and we should perhaps contact these
>people and try to convince them to re-use existing code (I
>am working now, for example, with Sophie Durand
> to convince her to re-use some
>exiting code for her classes). But I believe that changing
>package names will not help to achieve it. We need different
>ways to convince them.
>
>
>
>>We could have even tried automating it with scripts that
>>
>>
>contain the
>
>
>>mappings of where current classes are and where they would
>>
>>
>be after
>
>
>>the 'refactor'-ing.
>>
>>
>>
> I agree that it would be useful to provide a refactoring
>tool - if we need to refactor. But, as I said, I do not
>think that refactoring will help us now.
>
> Sorry for not agreeing with you on the package name
>changes. But I still believe that providing hints how to
>name their code would be very helpful.
>
> Martin
>
>PS. Btw, feel free to reproduce our conversation on the
>biomoby-dev list if you wish. M.
>
>--
>Martin Senger
>
>-----------Eddie-------------
>
>Thanks for your comments, I think that I should rethink this
>whole issue and then get back to you.
>
>Eddie
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>
How about some ant tasks that would make registration to the central
possible in a build file?
From senger at ebi.ac.uk Tue Mar 22 09:23:53 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 09:23:53 +0000 (GMT)
Subject: Ant tasks (was: [MOBY-dev] Java packages conversation)
In-Reply-To: <423FDB52.1000603@infobiogen.fr>
Message-ID:
> How about some ant tasks that would make registration to the central
> possible in a build file?
>
It is surely possible, but Ant is not helpful too much in this case -
at least I think:
The registration can be achieved by calling MobyCmdLineClient - and
this can be done perfectly from Ant (Ant task can easily set CLASSPATH and
call a Java application - MobyCmdLineClient is a Java application, of
course). The problem starts with the parameters for this application (and
there may be really *many* parameters for the registration). I have not
find a way how to pass to an Ant target parameters from the Ant's
command-line (let me know please if anybody knows how to do it).
Therefore, you have to expressed all parameters as Java properties, let
Ant to put them in a file and then feed an application (it can be again a
slightly modified MobyCmdLineClient, here is no problem) from this file.
So you have to do a lot of writing (setting properties) before you invoke
Ant - perhaps the same amount but I guess even more than writing a short
script where you can put all your registration parameters directly.
That's why I think that Ant is not too helpful for making registration.
But if people think that it should be there I can make such Ant target.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From ywong at infobiogen.fr Tue Mar 22 10:30:05 2005
From: ywong at infobiogen.fr (Yan Wong)
Date: Tue, 22 Mar 2005 11:30:05 +0100
Subject: [MOBY-dev] Re: Ant tasks
In-Reply-To:
References:
Message-ID: <423FF3AD.2030000@infobiogen.fr>
Martin Senger wrote:
>>How about some ant tasks that would make registration to the central
>>possible in a build file?
>>
>>
>>
> It is surely possible, but Ant is not helpful too much in this case -
>at least I think:
> The registration can be achieved by calling MobyCmdLineClient - and
>this can be done perfectly from Ant (Ant task can easily set CLASSPATH and
>call a Java application - MobyCmdLineClient is a Java application, of
>course). The problem starts with the parameters for this application (and
>there may be really *many* parameters for the registration). I have not
>find a way how to pass to an Ant target parameters from the Ant's
>command-line (let me know please if anybody knows how to do it).
>Therefore, you have to expressed all parameters as Java properties, let
>Ant to put them in a file and then feed an application (it can be again a
>slightly modified MobyCmdLineClient, here is no problem) from this file.
>So you have to do a lot of writing (setting properties) before you invoke
>Ant - perhaps the same amount but I guess even more than writing a short
>script where you can put all your registration parameters directly.
> That's why I think that Ant is not too helpful for making registration.
>But if people think that it should be there I can make such Ant target.
>
> Cheers,
> Martin
>
>
>
I thought it was possible to add registration tasks as bioMoby
registration requests are XML.
Something like could exit in an ant build file:
Maybe we do not need to fully translate a request in an ant like syntax
but make the ant task understand the moby request
An ant task would look like this:
mobyPhytoprotGetByAGICodeRetrievalgenoplante-info.infobiogen.frhttp://genoplante-info.infobiogen.fr/webservices/phytoprot-planet.pygpsupport at infobiogen.fr0Access to Phytoprot's clusters, by accession
numberObjectAGI_LocusCodeStringAvsAAvsAAvsP
It would use the existant bioMoby XML syntax to describes tasks/parameters.
Regards
Yan
From senger at ebi.ac.uk Tue Mar 22 11:05:53 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 11:05:53 +0000 (GMT)
Subject: [MOBY-dev] Java packages conversation (was: What versions of
JAVA is everyone using?)
In-Reply-To: <423f00fb.14d19c85.67e0.0ec1@mx.gmail.com>
Message-ID:
> May I ask you what it was you thought would be placed in the
> packages client, shared, and registry when you created them?
>
Sure. (I am quoting partly from the jMoby API documentation. And I am
going to put these more detailed answers back there.)
Just a note (repeating what was already said in this thread): these are
meant to be high-level package names - and everybody is welcome to make
more specialized packages *within* (below) these packages. However, please
be aware that making a directory under CVS is a *big* change which is hard
to redo - so think twice before you commit a new directory.
'org.biomoby.clients' contains components used to develop Moby clients.
The Moby clients can be both clients of the Moby registry and clients of
the Moby services. It can also contain not only components but full
clients (even though I have put my full command-line client
MobyCmdLineClient elsewhere because of some obscure reasons I have not
put that client into any package).
'org.biomoby.registry' contains components helping with Moby registry.
These components are supposed to be used by those who are running a
registry. At the moment, there is not many components here, because most
of the registry implementation is in Perl. Note that if you write code
that *uses* registry by calling its API methods you should put it into the
'org.biomoby.client' package because in fact you are the clients of the
registry. Here should go components that use direct access to the registry
databases (like a direct JDBC access), or here we may have
Java-implementation of the whole registry soemday.
'org.biomoby.service' (which should be called actually better
'org.biomoby.services' - my fault) contains general components that can be
used by those writing code for moby services. This is not meant to be used
for the service-specific code - such some business logic to get to a plant
database at MIPS (for that I assume the developer will have his/her own
package name which is not committed to the jMoby CVS) - but for general
components that can be re-used by any/many service providers for their
services. Also here can go some example services that can be used as
templates for service providers.
And finally 'org.biomoby.shared' contains components that are used by
classes from more than one package above. The bottom-line (or a
bottom-rule) is: If one wants to run clients, it must be sufficent for him
to pack all classes from 'org.biomoby.client' *and* 'org.biomoby.shared'
only. If one wants to create a registry oriented component, it is enough
for him to pack 'org.biomoby.registry' *and* 'org.biomoby.shared'. And
similarly for service providers which would pack ''org.biomoby.service'
*and* 'org.biomoby.shared'.
Additionally the 'org.biomoby.shared' package is a good place for
putting there Java interfaces - assuming that they are expected to use
more generally. So I have put here Central.java - an interface defining an
access to a Moby registry - because I felt (and I still feel) that there
may be a component (using this interface) in other package than in
'org.biomoby.client'.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Tue Mar 22 11:40:03 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 11:40:03 +0000 (GMT)
Subject: [MOBY-dev] Re: Ant tasks
In-Reply-To: <423FF3AD.2030000@infobiogen.fr>
Message-ID:
> Something like could exit in an ant build file:
>
Thanks for your example. I apologize but I strongly oppose it. And I am
sorry that I perhaps have not expressed things clearly. There are two
arguments why your example should not be put, as it was suggested, into
Ant's build.xml (and I am talking about the build.xml distributed in jMoby
CVS; if you talk about your own build.xml somewhere in your local copy of
jMoby, your example is perfectly fine):
1) The build.xml is a general file that is used by anybody building
jMoby and using jMoby. So it cannot have specific things dealing with a
particular service, such as
PhytoprotGetByAGICode. One *can* have such
things in an Ant's build.xml if it is defined as a property - and one is
free to define his/her own properties either on Ant command line, or in a
local build.properties file. So your example would be something like:
${service.name}
and you have to put into your build.properties file a line:
service.name = PhytoprotGetByAGICode
or you would invoke jMoby Ant by typing:
./build-dev.sh -Dservice.name=PhytoprotGetByAGICode register
But considering how many properties one needs to set, it would be a lot of
writing - that's what I was talkeing about in my previous mail.
2) This is not a strong argument - and there may be other opinions on
that - but I feel like this: In jMoby (and AFAIK it is the same within the
perl moby libraries), you are encouraged not to use directly XML requested
by Moby registry but rather to use an API to access such registry. In
jMoby case it is a Java API defined in Central.java. Using this, you are
shared by potential changes in the native (XML-based) Moby API. Therefore,
I would not recommed to register your services by defining XML at all (not
only as a part of an Ant's build.xml).
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Tue Mar 22 12:12:17 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Tue, 22 Mar 2005 12:12:17 +0000 (GMT)
Subject: [MOBY-dev] Java packages conversation
In-Reply-To: <423F05CE.1060801@ucalgary.ca>
Message-ID:
> -What about the data templates and instances?
>
What are data templates and instances?
> Is org.biomoby.shared going away? Should there be a org.biomoby.data
> instead?
>
I hope I have explained things in my previous email.
'org.biomoby.shared' will stay (as far as I can tell). If you feel a need
for a sub-package containing data structure feel free to create
'org.biomoby.shared.data' (but at the moment I am not going to move there
any of my data classes - simple, as explained earlier, it is too many
changes in the users code which is not justified now - I believe).
> -Where should server side or combines server/client objects (e.g.
> MobyRequest) go?
>
Why do you think that MobyRequest is a server/client combination? Do
you mean perhaps service/client combination? If that is the case, I think
this class should be in 'org.biomoby.shared' (or it its subpackage of your
choice). If this class is used only by clients (when they call a moby
service) then it should go to 'org.biomoby.client'.
Cheers,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From gss at ncgr.org Tue Mar 22 18:46:09 2005
From: gss at ncgr.org (Gary Schiltz)
Date: Tue, 22 Mar 2005 11:46:09 -0700
Subject: [moby] [MOBY-dev] About serviceNotes block
In-Reply-To: <1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
References: <4235B3B6.7090508@cnb.uam.es>
<1110826530.29060.101.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424067F1.10603@ncgr.org>
Not at the moment, but it does seem important to have a place to return
error messages. It is particularly important in a distributed
environment, since there are so many things that can go wrong
(transmission errors, servers being down, ...).
// Gary
Mark Wilkinson wrote:
>Damian/Gary - does S-MOBY have a place in the canonical RDF to stick
>provision information data? Do you have a defined set of predicates for
>that?
>
From senger at ebi.ac.uk Wed Mar 23 15:24:12 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Wed, 23 Mar 2005 15:24:12 +0000 (GMT)
Subject: [MOBY-dev] problems with Moby central
In-Reply-To: <1110906365.2107.18.camel@mobycentral.icapture.ubc.ca>
Message-ID:
Mark,
It seems that the Moby Central is broken at the moment. It cannot even
return a list of services. Instead it reports about an XML parse
exception. Would you mind to look at it please?
Many thanks,
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From mwilkinson at mrl.ubc.ca Wed Mar 23 16:05:45 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 23 Mar 2005 08:05:45 -0800
Subject: [MOBY-dev] mobycentral revived
Message-ID: <1111593945.22484.18.camel@mobycentral.icapture.ubc.ca>
Hi all,
sorry about that - I was in post-surgery with my cat when it went down
and I never got back on-line until this AM.
MOBY Central is a bit flaky at the moment, and we can't figure out why.
It is a rather sudden flakyness that doesn't seem to correspond to any
particular change we have made. The Apache error logs fill up with
segfaults within a couple of hours and that crashes the system as the
amount of available memory goes to zero. MySQL seems to be having a
similar problem (it was mysql that had crashed last night). This all
seems to point to a physical memory error, but we can't detect one...
It may be time to get a new machine for MOBY :-)
Anyway, I'll keep an eye on it throughout the day. I have turned
apache's error logging to "critical" to reduce teh number of error
messages, so hopefully we'll have longer availability between crashes.
Sorry about this!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 23 16:53:44 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 23 Mar 2005 08:53:44 -0800
Subject: [MOBY-dev] recompiling Apache
Message-ID: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Hi everyone,
I've just found a posting that suggests that there is a conflict between
expat and apache. Expat is the XML parser that I believe is part of
libxml2 which is what is used by XML::LibXML - the new libraries that
are doing the XML parsing for MOBY Central.
I will need to recompile Apache to fix this problem (if it is the
problem...), so you might notice mobycentral going up and down over the
next 48 hours as I play with it, but I will try to limit my testing to
the test instance of the server so that it doesn't disturb anyone too
badly.
Sorry for the flakyness!
M
(this doesn't explain the crash of mysql... but it might just have been
a coincidence...)
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From mwilkinson at mrl.ubc.ca Wed Mar 23 20:43:07 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 23 Mar 2005 12:43:07 -0800
Subject: [MOBY-dev] Cut-off for MOBY-DIC registration: March 31, 2005.
Message-ID: <1111610587.24448.12.camel@mobycentral.icapture.ubc.ca>
Hi all,
Particularly pinging the S-MOBY crew, the CSHL crew, the Brisbane crew,
and anyone from myGrid or GO who wants to spend a few days away from the
dull Manchester/Hinxton rain lapping up the sun in Lotus Land :-) If
you have not registered yet, go to:
http://biomoby.org/cgi-bin/register.cgi
In order to make a budget and book the catering I have to set a cut-off
date for the MOBY DIC meeting registration. March 31st will be the last
date for attendees who want to take advantage of the substantially
discounted registration supplement from my Genome Canada grant, after
which you will be responsible for paying your own room and board.
So... if you haven't already registered... get on y'r horse! :-)
If you aren't sure if you have registered, go to
http://biomoby.org/regisrations.txt
I will make the final budget on the 1st of April and then will be able
to let you know exactly what the registration fees will be (including 3
nights and breakfast/lunch and coffee breaks for the the meeting days).
I'm still expecting this to be under $200, probably well under that
number.
Cheers all!
M
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From senger at ebi.ac.uk Thu Mar 24 00:09:24 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 24 Mar 2005 00:09:24 +0000 (GMT)
Subject: [MOBY-dev] recompiling Apache
In-Reply-To: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Message-ID:
> I've just found a posting that suggests that there is a conflict between
> expat and apache. Expat is the XML parser that I believe is part of
> libxml2
>
FYI, I do not know about libxml12 but I know that Expat is a base part
for XML::Parser.
I wish you luck with finding the cause of problems.
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From senger at ebi.ac.uk Thu Mar 24 00:09:24 2005
From: senger at ebi.ac.uk (Martin Senger)
Date: Thu, 24 Mar 2005 00:09:24 +0000 (GMT)
Subject: [MOBY-dev] recompiling Apache
In-Reply-To: <1111596824.22717.28.camel@mobycentral.icapture.ubc.ca>
Message-ID:
> I've just found a posting that suggests that there is a conflict between
> expat and apache. Expat is the XML parser that I believe is part of
> libxml2
>
FYI, I do not know about libxml12 but I know that Expat is a base part
for XML::Parser.
I wish you luck with finding the cause of problems.
Martin
--
Martin Senger
EMBL Outstation - Hinxton Senger at EBI.ac.uk
European Bioinformatics Institute Phone: (+44) 1223 494636
Wellcome Trust Genome Campus (Switchboard: 494444)
Hinxton Fax : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom http://industry.ebi.ac.uk/~senger
From markw at illuminae.com Thu Mar 24 02:40:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 23 Mar 2005 18:40:40 -0800
Subject: [MOBY-dev] recompiling Apache
In-Reply-To:
References:
Message-ID: <424228A8.5040507@illuminae.com>
It seems to have settled down a bit now. All I did was install a newer
version of DBI!
There's still a segfault in the error log that happened some time in the
past 6 hours, but that is better than the several dozen per hour that
were happening a few days ago :-)
I'll keep an eye on it, but for now it seems somewhat stable (touch wood!)
M
Martin Senger wrote:
>>I've just found a posting that suggests that there is a conflict between
>>expat and apache. Expat is the XML parser that I believe is part of
>>libxml2
>>
>>
>>
> FYI, I do not know about libxml12 but I know that Expat is a base part
>for XML::Parser.
>
> I wish you luck with finding the cause of problems.
> Martin
>
>
>
From markw at illuminae.com Thu Mar 24 02:40:40 2005
From: markw at illuminae.com (Mark Wilkinson)
Date: Wed, 23 Mar 2005 18:40:40 -0800
Subject: [MOBY-dev] recompiling Apache
In-Reply-To:
References:
Message-ID: <424228A8.5040507@illuminae.com>
It seems to have settled down a bit now. All I did was install a newer
version of DBI!
There's still a segfault in the error log that happened some time in the
past 6 hours, but that is better than the several dozen per hour that
were happening a few days ago :-)
I'll keep an eye on it, but for now it seems somewhat stable (touch wood!)
M
Martin Senger wrote:
>>I've just found a posting that suggests that there is a conflict between
>>expat and apache. Expat is the XML parser that I believe is part of
>>libxml2
>>
>>
>>
> FYI, I do not know about libxml12 but I know that Expat is a base part
>for XML::Parser.
>
> I wish you luck with finding the cause of problems.
> Martin
>
>
>
From edward.kawas at gmail.com Tue Mar 29 16:24:44 2005
From: edward.kawas at gmail.com (Eddie Kawas)
Date: Tue, 29 Mar 2005 08:24:44 -0800
Subject: [MOBY-dev] Java packages conversation
In-Reply-To:
Message-ID: <4249814d.41902bab.69a1.43e9@mx.gmail.com>
Hi,
I have a structure that I would like comments and
suggestions on. Some of the code is neither yet documented
nor available on the cvs, but I was hoping to see what
everyone thinks anyways.
I basically used the 3 current packages (shared, client and
registry) and created some detailed packages underneath
them. I produced some java documentation and uploaded it to
http://bioinfo.icapture.ubc.ca/ekawas/doc/.
Thanks,
Eddie
From mwilkinson at mrl.ubc.ca Wed Mar 30 22:48:40 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 30 Mar 2005 14:48:40 -0800
Subject: [MOBY-dev] LSID's are running again :-)
Message-ID: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Hi all,
The LSID resolver for MOBY LSID's is up and running again thanks to
Eddie and with help and advice from Stephen Evanchik at IBM.
I've also written a little CGI form that will resolve a MOBY LSID to the
screen for viewing. This is available under the "Cool Tools" link from
the MOBY homepage.
Cheers all!
M
(reminder - just one more day to register for the MOBY meeting at a
discount rate!!)
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 00:04:27 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Wed, 30 Mar 2005 17:04:27 -0700
Subject: [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424B3E8B.5070607@cpsc.ucalgary.ca>
Hi All,
I am new to Moby. I followed the Fasta example service to create our
svervice. How do I register our service to Moby Centrol? could Anyone
let me know about?
Thanks,
Joyce
Mark Wilkinson wrote:
>Hi all,
>
>The LSID resolver for MOBY LSID's is up and running again thanks to
>Eddie and with help and advice from Stephen Evanchik at IBM.
>
>I've also written a little CGI form that will resolve a MOBY LSID to the
>screen for viewing. This is available under the "Cool Tools" link from
>the MOBY homepage.
>
>Cheers all!
>
>M
>
>(reminder - just one more day to register for the MOBY meeting at a
>discount rate!!)
>
>
>
>
From wangch at cpsc.ucalgary.ca Thu Mar 31 00:04:27 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Wed, 30 Mar 2005 17:04:27 -0700
Subject: [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424B3E8B.5070607@cpsc.ucalgary.ca>
Hi All,
I am new to Moby. I followed the Fasta example service to create our
svervice. How do I register our service to Moby Centrol? could Anyone
let me know about?
Thanks,
Joyce
Mark Wilkinson wrote:
>Hi all,
>
>The LSID resolver for MOBY LSID's is up and running again thanks to
>Eddie and with help and advice from Stephen Evanchik at IBM.
>
>I've also written a little CGI form that will resolve a MOBY LSID to the
>screen for viewing. This is available under the "Cool Tools" link from
>the MOBY homepage.
>
>Cheers all!
>
>M
>
>(reminder - just one more day to register for the MOBY meeting at a
>discount rate!!)
>
>
>
>
From mwilkinson at mrl.ubc.ca Thu Mar 31 00:18:06 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Wed, 30 Mar 2005 16:18:06 -0800
Subject: [moby] [MOBY-dev] How to register the service to Moby
In-Reply-To: <424B3E8B.5070607@cpsc.ucalgary.ca>
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
<424B3E8B.5070607@cpsc.ucalgary.ca>
Message-ID: <1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
Hi Joyce,
When you say "the Fasta example" which example do you mean? Can you
send the URL?
To answer your question - on this page:
http://www.biomoby.org/tutorials.html
there is a tutorial that includes information about how to register your
service in MOBY Central.
If you don't want to do it through code, there is also a web based GUI
written by Eddie Kawas that will help you register your service - you
can get to it by clicking the appropriate link from the Tools and Toys
page (http://www.biomoby.org/toolstoys.html).
Unfortunately, MOBY Central has just crashed... badly... and I need
someone to reboot it, but it is on the other side of the continent so it
might take a while until someone notices. As such, you will have to
wait for a while until you will be able to register your service. Sorry
about that! It doesn't happen very often...
Let me know if you need any more help.
Cheers!
Mark
On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
> Hi All,
> I am new to Moby. I followed the Fasta example service to create our
> svervice. How do I register our service to Moby Centrol? could Anyone
> let me know about?
> Thanks,
>
> Joyce
>
> Mark Wilkinson wrote:
>
> >Hi all,
> >
> >The LSID resolver for MOBY LSID's is up and running again thanks to
> >Eddie and with help and advice from Stephen Evanchik at IBM.
> >
> >I've also written a little CGI form that will resolve a MOBY LSID to the
> >screen for viewing. This is available under the "Cool Tools" link from
> >the MOBY homepage.
> >
> >Cheers all!
> >
> >M
> >
> >(reminder - just one more day to register for the MOBY meeting at a
> >discount rate!!)
> >
> >
> >
> >
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 18:38:08 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Thu, 31 Mar 2005 11:38:08 -0700
Subject: [moby] [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca> <424B3E8B.5070607@cpsc.ucalgary.ca>
<1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424C4390.5010305@cpsc.ucalgary.ca>
Hi Mark,
I say "the Fasta Example Service" which is at the URL:
http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
MobyEd_dispatcher.cgi for HMM search. I have a function for registering
service to Moby in the Hmm_test_central.pl.
I think when I run Hmm_test_central.pl, them HMM service will be
registered in Moby center. But I use the command line to check it, it is
not registered. I am not clear about this. Do we get any email from Moby
once the service is registered?
Anyway, Thank you for the information. I will check the tutorial again.
I guess that I may did not correct.
Regards,
Joyce
Mark Wilkinson wrote:
>Hi Joyce,
>
>When you say "the Fasta example" which example do you mean? Can you
>send the URL?
>
>To answer your question - on this page:
>http://www.biomoby.org/tutorials.html
>
>there is a tutorial that includes information about how to register your
>service in MOBY Central.
>
>If you don't want to do it through code, there is also a web based GUI
>written by Eddie Kawas that will help you register your service - you
>can get to it by clicking the appropriate link from the Tools and Toys
>page (http://www.biomoby.org/toolstoys.html).
>
>Unfortunately, MOBY Central has just crashed... badly... and I need
>someone to reboot it, but it is on the other side of the continent so it
>might take a while until someone notices. As such, you will have to
>wait for a while until you will be able to register your service. Sorry
>about that! It doesn't happen very often...
>
>Let me know if you need any more help.
>
>Cheers!
>
>Mark
>
>
>
>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>
>
>>Hi All,
>>I am new to Moby. I followed the Fasta example service to create our
>>svervice. How do I register our service to Moby Centrol? could Anyone
>>let me know about?
>>Thanks,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi all,
>>>
>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>Eddie and with help and advice from Stephen Evanchik at IBM.
>>>
>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>screen for viewing. This is available under the "Cool Tools" link from
>>>the MOBY homepage.
>>>
>>>Cheers all!
>>>
>>>M
>>>
>>>(reminder - just one more day to register for the MOBY meeting at a
>>>discount rate!!)
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
From mwilkinson at mrl.ubc.ca Thu Mar 31 18:50:21 2005
From: mwilkinson at mrl.ubc.ca (Mark Wilkinson)
Date: Thu, 31 Mar 2005 10:50:21 -0800
Subject: [moby] [MOBY-dev] How to register the service to Moby
In-Reply-To: <424C4390.5010305@cpsc.ucalgary.ca>
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca>
<424B3E8B.5070607@cpsc.ucalgary.ca>
<1112228286.5297.11.camel@mobycentral.icapture.ubc.ca>
<424C4390.5010305@cpsc.ucalgary.ca>
Message-ID: <1112295021.9268.10.camel@mobycentral.icapture.ubc.ca>
Hi Chunyan,
Please tell me where you found the link to that website - I am trying to
"squash" them all :-)
That particular tutorial, and the code modules that are described in it,
are significantly out of date, and *will not* result in functional
services under the new API.
Please follow the tutorial on the website that I sent you yesterday.
Unfortunately, MOBY Central has crashed AGAIN this morning so you will
not be able to register your service there until it is restarted... I
still have not found the source of these ongoing problems but the
crashes are getting worse - I can't even log in to that machine
anymore. If I cannot find the source of these problems by the end of
the week I will ask everyone to point their code at the mirror of MOBY
Central that I am running here in Vancouver, since it seems to be more
stable.
>>sigh<<
Cheers all
M
On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
> Hi Mark,
> I say "the Fasta Example Service" which is at the URL:
> http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
> I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
> MobyEd_dispatcher.cgi for HMM search. I have a function for registering
> service to Moby in the Hmm_test_central.pl.
> I think when I run Hmm_test_central.pl, them HMM service will be
> registered in Moby center. But I use the command line to check it, it is
> not registered. I am not clear about this. Do we get any email from Moby
> once the service is registered?
> Anyway, Thank you for the information. I will check the tutorial again.
> I guess that I may did not correct.
>
> Regards,
>
> Joyce
>
> Mark Wilkinson wrote:
>
> >Hi Joyce,
> >
> >When you say "the Fasta example" which example do you mean? Can you
> >send the URL?
> >
> >To answer your question - on this page:
> >http://www.biomoby.org/tutorials.html
> >
> >there is a tutorial that includes information about how to register your
> >service in MOBY Central.
> >
> >If you don't want to do it through code, there is also a web based GUI
> >written by Eddie Kawas that will help you register your service - you
> >can get to it by clicking the appropriate link from the Tools and Toys
> >page (http://www.biomoby.org/toolstoys.html).
> >
> >Unfortunately, MOBY Central has just crashed... badly... and I need
> >someone to reboot it, but it is on the other side of the continent so it
> >might take a while until someone notices. As such, you will have to
> >wait for a while until you will be able to register your service. Sorry
> >about that! It doesn't happen very often...
> >
> >Let me know if you need any more help.
> >
> >Cheers!
> >
> >Mark
> >
> >
> >
> >On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
> >
> >
> >>Hi All,
> >>I am new to Moby. I followed the Fasta example service to create our
> >>svervice. How do I register our service to Moby Centrol? could Anyone
> >>let me know about?
> >>Thanks,
> >>
> >>Joyce
> >>
> >>Mark Wilkinson wrote:
> >>
> >>
> >>
> >>>Hi all,
> >>>
> >>>The LSID resolver for MOBY LSID's is up and running again thanks to
> >>>Eddie and with help and advice from Stephen Evanchik at IBM.
> >>>
> >>>I've also written a little CGI form that will resolve a MOBY LSID to the
> >>>screen for viewing. This is available under the "Cool Tools" link from
> >>>the MOBY homepage.
> >>>
> >>>Cheers all!
> >>>
> >>>M
> >>>
> >>>(reminder - just one more day to register for the MOBY meeting at a
> >>>discount rate!!)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>MOBY-dev mailing list
> >>MOBY-dev at biomoby.org
> >>http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
Assistant Professor (Bioinformatics)
Dept. Medical Genetics, UBC, Canada
From wangch at cpsc.ucalgary.ca Thu Mar 31 20:30:36 2005
From: wangch at cpsc.ucalgary.ca (Chunyan Wang)
Date: Thu, 31 Mar 2005 13:30:36 -0700
Subject: [moby] [MOBY-dev] How to register the service to Moby
References: <1112222920.3843.123.camel@mobycentral.icapture.ubc.ca> <424B3E8B.5070607@cpsc.ucalgary.ca> <1112228286.5297.11.camel@mobycentral.icapture.ubc.ca> <424C4390.5010305@cpsc.ucalgary.ca>
<1112295021.9268.10.camel@mobycentral.icapture.ubc.ca>
Message-ID: <424C5DEC.50104@cpsc.ucalgary.ca>
Hi Mark,
I think I just found it on Google. I will check the tutorial on the
website that you sent to me yesterday. By the way, do you a sample of
codes in Perl (for new API)? If you have it, could you send them to me?
If you don't have, don't worry about it. I will find them in tutorial, I
guess.
Thanks,
Regards,
Chunyan or Joyce
Mark Wilkinson wrote:
>Hi Chunyan,
>
>Please tell me where you found the link to that website - I am trying to
>"squash" them all :-)
>
>That particular tutorial, and the code modules that are described in it,
>are significantly out of date, and *will not* result in functional
>services under the new API.
>
>Please follow the tutorial on the website that I sent you yesterday.
>
>Unfortunately, MOBY Central has crashed AGAIN this morning so you will
>not be able to register your service there until it is restarted... I
>still have not found the source of these ongoing problems but the
>crashes are getting worse - I can't even log in to that machine
>anymore. If I cannot find the source of these problems by the end of
>the week I will ask everyone to point their code at the mirror of MOBY
>Central that I am running here in Vancouver, since it seems to be more
>stable.
>
>
>
>>>sigh<<
>>>
>>>
>
>Cheers all
>
>M
>
>
>
>
>
>On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
>
>
>>Hi Mark,
>>I say "the Fasta Example Service" which is at the URL:
>>http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
>>I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
>>MobyEd_dispatcher.cgi for HMM search. I have a function for registering
>>service to Moby in the Hmm_test_central.pl.
>>I think when I run Hmm_test_central.pl, them HMM service will be
>>registered in Moby center. But I use the command line to check it, it is
>>not registered. I am not clear about this. Do we get any email from Moby
>>once the service is registered?
>>Anyway, Thank you for the information. I will check the tutorial again.
>>I guess that I may did not correct.
>>
>>Regards,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi Joyce,
>>>
>>>When you say "the Fasta example" which example do you mean? Can you
>>>send the URL?
>>>
>>>To answer your question - on this page:
>>>http://www.biomoby.org/tutorials.html
>>>
>>>there is a tutorial that includes information about how to register your
>>>service in MOBY Central.
>>>
>>>If you don't want to do it through code, there is also a web based GUI
>>>written by Eddie Kawas that will help you register your service - you
>>>can get to it by clicking the appropriate link from the Tools and Toys
>>>page (http://www.biomoby.org/toolstoys.html).
>>>
>>>Unfortunately, MOBY Central has just crashed... badly... and I need
>>>someone to reboot it, but it is on the other side of the continent so it
>>>might take a while until someone notices. As such, you will have to
>>>wait for a while until you will be able to register your service. Sorry
>>>about that! It doesn't happen very often...
>>>
>>>Let me know if you need any more help.
>>>
>>>Cheers!
>>>
>>>Mark
>>>
>>>
>>>
>>>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>>>
>>>
>>>
>>>
>>>>Hi All,
>>>>I am new to Moby. I followed the Fasta example service to create our
>>>>svervice. How do I register our service to Moby Centrol? could Anyone
>>>>let me know about?
>>>>Thanks,
>>>>
>>>>Joyce
>>>>
>>>>Mark Wilkinson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>>>Eddie and with help and advice from Stephen Evanchik at IBM.
>>>>>
>>>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>>>screen for viewing. This is available under the "Cool Tools" link from
>>>>>the MOBY homepage.
>>>>>
>>>>>Cheers all!
>>>>>
>>>>>M
>>>>>
>>>>>(reminder - just one more day to register for the MOBY meeting at a
>>>>>discount rate!!)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev at biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
From markw at illuminae.com Thu Mar 31 22:07:36 2005
From: markw at illuminae.com (mark wilkinson)
Date: Thu, 31 Mar 2005 22:07:36 +0000 GMT
Subject: [moby] [MOBY-dev] How to register the service to Moby
Message-ID: <212712647-1112306868-cardhu_blackberry.rim.net-32084-@engine11-cell01>
The tutorial has tons of code, and all of the services that I run have their code in the moby-live/Perl/scripts/Services/LocalServices.pm module in the cvs
That should get you started :-)
Cheers!
M
-----Original Message-----
From: Chunyan Wang
Date: Thu, 31 Mar 2005 13:30:36
To:Core developer announcements
Subject: Re: [moby] [MOBY-dev] How to register the service to Moby
Hi Mark,
I think I just found it on Google. I will check the tutorial on the
website that you sent to me yesterday. By the way, do you a sample of
codes in Perl (for new API)? If you have it, could you send them to me?
If you don't have, don't worry about it. I will find them in tutorial, I
guess.
Thanks,
Regards,
Chunyan or Joyce
Mark Wilkinson wrote:
>Hi Chunyan,
>
>Please tell me where you found the link to that website - I am trying to
>"squash" them all :-)
>
>That particular tutorial, and the code modules that are described in it,
>are significantly out of date, and *will not* result in functional
>services under the new API.
>
>Please follow the tutorial on the website that I sent you yesterday.
>
>Unfortunately, MOBY Central has crashed AGAIN this morning so you will
>not be able to register your service there until it is restarted... I
>still have not found the source of these ongoing problems but the
>crashes are getting worse - I can't even log in to that machine
>anymore. If I cannot find the source of these problems by the end of
>the week I will ask everyone to point their code at the mirror of MOBY
>Central that I am running here in Vancouver, since it seems to be more
>stable.
>
>
>
>>>sigh<<
>>>
>>>
>
>Cheers all
>
>M
>
>
>
>
>
>On Thu, 2005-03-31 at 10:38, Chunyan Wang wrote:
>
>
>>Hi Mark,
>>I say "the Fasta Example Service" which is at the URL:
>>http://plantgenome.sdsc.edu/mobyed2/Fasta_Service/.
>>I have a set of codes: Hmm_test_central.pl, HMMSearch.pm,
>>MobyEd_dispatcher.cgi for HMM search. I have a function for registering
>>service to Moby in the Hmm_test_central.pl.
>>I think when I run Hmm_test_central.pl, them HMM service will be
>>registered in Moby center. But I use the command line to check it, it is
>>not registered. I am not clear about this. Do we get any email from Moby
>>once the service is registered?
>>Anyway, Thank you for the information. I will check the tutorial again.
>>I guess that I may did not correct.
>>
>>Regards,
>>
>>Joyce
>>
>>Mark Wilkinson wrote:
>>
>>
>>
>>>Hi Joyce,
>>>
>>>When you say "the Fasta example" which example do you mean? Can you
>>>send the URL?
>>>
>>>To answer your question - on this page:
>>>http://www.biomoby.org/tutorials.html
>>>
>>>there is a tutorial that includes information about how to register your
>>>service in MOBY Central.
>>>
>>>If you don't want to do it through code, there is also a web based GUI
>>>written by Eddie Kawas that will help you register your service - you
>>>can get to it by clicking the appropriate link from the Tools and Toys
>>>page (http://www.biomoby.org/toolstoys.html).
>>>
>>>Unfortunately, MOBY Central has just crashed... badly... and I need
>>>someone to reboot it, but it is on the other side of the continent so it
>>>might take a while until someone notices. As such, you will have to
>>>wait for a while until you will be able to register your service. Sorry
>>>about that! It doesn't happen very often...
>>>
>>>Let me know if you need any more help.
>>>
>>>Cheers!
>>>
>>>Mark
>>>
>>>
>>>
>>>On Wed, 2005-03-30 at 16:04, Chunyan Wang wrote:
>>>
>>>
>>>
>>>
>>>>Hi All,
>>>>I am new to Moby. I followed the Fasta example service to create our
>>>>svervice. How do I register our service to Moby Centrol? could Anyone
>>>>let me know about?
>>>>Thanks,
>>>>
>>>>Joyce
>>>>
>>>>Mark Wilkinson wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi all,
>>>>>
>>>>>The LSID resolver for MOBY LSID's is up and running again thanks to
>>>>>Eddie and with help and advice from Stephen Evanchik at IBM.
>>>>>
>>>>>I've also written a little CGI form that will resolve a MOBY LSID to the
>>>>>screen for viewing. This is available under the "Cool Tools" link from
>>>>>the MOBY homepage.
>>>>>
>>>>>Cheers all!
>>>>>
>>>>>M
>>>>>
>>>>>(reminder - just one more day to register for the MOBY meeting at a
>>>>>discount rate!!)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>MOBY-dev mailing list
>>>>MOBY-dev at biomoby.org
>>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>>>
>>>>
>>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev
--
Mark Wilkinson
...on the road!