Martin - is the XML schema available somewhere? I can't find it from the webpage...
Tom
Patrick McConnell wrote:
For maximum flexibility and ease of use, I think describing the parameters in an external (editable) file would be preferrable. I do not think it would be too hard to come up with an XML schema for describing how programs should be run. Something like:
<program> <name>NCBI Blast</name> <parameterSet> <platform>default</platform> <flag>-</flag> <delimiter> </delimiter> <parameter> <name>p</name> <description>blast program</description> <allowableValues> <allowableValue>blastn</allowableValue> <allowableValue>blastp</allowableValue> <allowableValue>blastx</allowableValue> </allowableValues> </parameter> . . . </parameterSet> </program>
You could define defaults that can be overridden per program, per platform, and per parameter. This way, users can easily add/change programs for their platform, and you do not need to rebuild BioJava for these changes.
The code for invoking the program would be like:
ExternalProgram prog = new ExternalProgram("NCBI Blast"); prog.addParameter("p", "blastn"); . . .
String stdin = null; StringBuffer stdout = new StringBuffer(); StringBuffer stderr = new StringBuffer(); prog.exec(pathToBlastall, stdin, stdout, stderr);
You could also query a particular program for its parameters, allowable values, defaults, etc.
Again, the file could be located and loaded from the BioJava jar, the directory the BioJava jar is in, and the user's home directory.
I would love to see something like this in BioJava. Please comment on the advantages/drawbacks of such a system because I am now considering implementing it for my own use!
-Patrick
"Schreiber, Mark" <[EMAIL PROTECTED]>@biojava.org on 08/12/2003 10:39:04 PM
Sent by: [EMAIL PROTECTED]
To: "Keith James" <[EMAIL PROTECTED]>, "Thomas Down" <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED]
Subject: RE: [Biojava-l] Running apps with Java
I would tend to agree with Keith. Making hardcoded command lines can loose platform independence pretty quickly. I would prefer to see users register their own command lines, preferences etc with some kind of registry object.
- Mark
-----Original Message----- From: Keith James [mailto:[EMAIL PROTECTED] Sent: Tue 12/08/2003 10:46 p.m. To: Thomas Down Cc: [EMAIL PROTECTED] Subject: Re: [Biojava-l] Running apps with Java
>>>>> "Thomas" == Thomas Down <[EMAIL PROTECTED]> writes:
[...]
Thomas> Yes, I quite agree. Although I think I'd prefer something Thomas> more like:
Thomas> params.addParameter(NCBIBlast.PROGRAM_NAME, "blastn")
Thomas> Have you looked at the AnnotationType class? We could Thomas> probably use those to do the parameter set validation.
IMO having program names hardcoded in the method names or even as parameters greatly increases the amount to code required for a typical system. A public exec method per program will result in a lots of methods and requires rebuilding the jars to deploy a new external program (same with static parameters specific to a program).
Having a single, generic exec method with a means of discovering local native programs is simpler and more maintainable. This can be done simply with ResourceBundles (which also means that one can internationalize for free)
e.g.
NCBIBlast_en_GB.properties
-p = String : Program name -d = String : Database, default = nr -i = String : Query file, default = stdin -e = Double : Expectation value (E), default = 10.0
etc.
NCBIBlast_fr.properties
-p = String : Nom de programme
etc.
I think it is important to allow end users to configure their biojava to run their native applications without writing any code.
Thomas> The other big win would be to do something at least Thomas> vaguely sane about finding executables. Hardcoded paths Thomas> aren't a problem if you are running on your own machines, Thomas> but if people want to deploy BioJava-based applications Thomas> widely, they really need to be able find blast on their Thomas> own...
You can do this simply by adding a key/value to the resouce giving the full path. Alternatively this keyed value could be the name of a JNDI resource etc. for situations which require it.
I've been running a simple Java-based workflow & execing system in anger for the past year (lots of different native programs) and native program maintenance requiring rebuilding production of jar files is not something I'd want to deal with.
cheers,
Keith
--
- Keith James <[EMAIL PROTECTED]> Microarray Facility, Team 65 - - The Wellcome Trust Sanger Institute, Hinxton, Cambridge, UK - _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
_______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
_______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
_______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
