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_output IntAct 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: moby PhytoprotGetByAGICode Retrieval genoplante-info.infobiogen.fr http://genoplante-info.infobiogen.fr/webservices/phytoprot-planet.py gpsupport@infobiogen.fr 0 Access to Phytoprot's clusters, by accession number Object AGI_LocusCode Object AGI_LocusCode String AvsA AvsA AvsP 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_output IntAct 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: moby PhytoprotGetByAGICode Retrieval genoplante-info.infobiogen.fr http://genoplante-info.infobiogen.fr/webservices/phytoprot-planet.py gpsupport at infobiogen.fr 0 Access to Phytoprot's clusters, by accession number Object AGI_LocusCode Object AGI_LocusCode String AvsA AvsA AvsP 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_output IntAct 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: moby PhytoprotGetByAGICode Retrieval genoplante-info.infobiogen.fr http://genoplante-info.infobiogen.fr/webservices/phytoprot-planet.py gpsupport at infobiogen.fr 0 Access to Phytoprot's clusters, by accession number Object AGI_LocusCode Object AGI_LocusCode String AvsA AvsA AvsP 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!