Author: markw

It was decided that the file .classpath.template will be committed to the CVS, and individual developers will have to rename it to .classpath themselves. Then changes to the classpath will not be committed back to the CVS

Martin’s presentation of the advantages, followed by discouragement from using it.

Ant and Maven are similar. What Maven does in addition is that it makes project dependencies and repositories. Therefore you can define the library that you code is using without having the library downloaded, you simply refer to it. it is then found and used in the build. Ant has a library called “ant maven library” that can accomplish the same thing. Martin will update the ant document he has made for GCP and will make it appropriate for the BioMoby homepage/documentation. You just install Ant and then build the project using “ant ”

Need to write to Chris Dag. to get added to the “maven” group so that we can use the maven repository on open-bio.

What belongs in the repository? Dashboard? It isn’t used for development… so should it be there?

People will be less intimidated by ant than by maven. So we agreed to use ant wtih the maven library.

Used to be only selected classes were documented, but now all classes are documented and it is confusing. Martin suggests re-documenting only those classes that are USED by developers.

Wendy’s experience was telling: she discovered CentralImpl after TWO MONTHS of studying the documentation! We need to document only the core classes and somehow provide a navigation/roadmap for newcomers.

Martin will look at the classes and make suggestions to the group about what the “core classes” are. Perhaps have two javadocs – one for all classes and one with only core classes.

Another example: there are three versions of CentralImpl in various places for various purposes. Need to be better documented.

ant – separate jar files into appropriate groups.

Mark needs to write an introduction to BioMoby that explains the basis of namespaces and objects. Need to document WHY Moby is better, and WHY certain decisions were made.

Start with a more detailed intro to Moby namespaces and datatypes
More detailed introduction to Dashboard
then split into Perl and Java streams

Errors: if the path to the project is too long then javadoc fails in ant.

A code release should include a snapshot of the cache of the registry for Dashboard.

Martin will make a CPAN release of Perl MoSeS including a snapshot of the registry. It’s currently hidden in the Java tree. Martin will bring it into a more obvious place.

Some of the problems setting up Java MoSeS in Eclipse were machine-specific.

Some problems were due to having three copies of the documentation for setting up (biomoby, tigr, and rws). Need to unify the documentation and keep one copy on biomoby.org updated. We’ll talk to Wendy about being the goddess of documentation. We’d like to have the API all in one document again, and to have the registry calls in e.g. BNF format. And get the links right!

Mark should see how difficult it is to do this… sometimes they can be empty…

Versioning

– Add to the registry API a way to determine the version of code it is running.

How to test services

– sample input and output will be part of service-provider’s RDF
– methods for testing services will become part of jMoby API
– will also have a panel in Dashboard (?)
– INB has extended metadata in Moby Central – this was for internal use and works best when the entire infrastructure is under some centralized control. Having service invocation examples in the hands of the service provider is more scalable and decentralized.
– do we need extra metadata? e.g. for testing asynchronous services? Perhaps using some sort of “type” of checking. is it alive? Does it take my input? does it give me a result? does the result match a particular pattern/filter? does the result match a predictable output?
– Martin will implement this in September sometime and will pass around the API to the group before implementation for comments

Registry issues:

Need a separate mailing list for Registry API updates?

Synchronization of registries needs to be formalized
– Andreas: Master & Secondary sync example
– LSID based
– filters + or – provides rules to exclude/include various services as they come in for sync
– Martin suggests adding this as a feature to jMoby and/or as a panel in Dashboard
– it should be fomalized somehow (the methodology and features)
– Andreas will take the lead on this issue, he will send out a list of features that are currently implemented, we will discuss (on list) what other features we want and Andreas will say yes/no as he sees fit, and he will make this functionality available in Dashboard.

Need releases on a regular schedule

Registry is a mishmash of Perl and Java

In attendance:

Mark, Eddie, Wendy, Richard, Ivan, Andreas, Paul, Martin, Mylah

We started with jokes about the danger of having the core Moby developers in the same room of a brick hospital built on top of a geological fault…

Issues that came up in introductory presentations:

Atrtribution of data to providers
– set logo? new methods…

Should the Object ontology have multiple representations for any given concept?
– e.g. FASTA and DNA Sequence are redundant…
– we need to find a way to encourage object re-use
– we need a “rule-base” to use the SeaHawk transformation rules rather than registering a new Moby object; or do we still need to register a new object?
– how much of this complexity should we expose the developers to?

In what order do we introduce the concepts of Moby to newcomers? How do we explain “the point” to newbies? The idea of data-type re-use, for example.

There’s no “one ring/protocol to rule them all”
– TAPIR/DIGR/BioCASE
– SSWAP
– Moby
– Gramene format

Ivan apologizes for his English 🙂
– it really isn’t as bad as he claims it is!

Need to support large datasets

Need to support document-encoded rather than RPC
– Java libraries no longer support RPC SOAP
– Perl library doesn’t support anything OTHER than RPC SOAP
– this is clearly a problem!

Support “template datatypes” to contain other kinds of objects

In attendance:

Mark, Eddie, Wendy, Richard, Ivan, Andreas, Paul, Martin, Mylah

We started with jokes about the danger of having the core Moby developers in the same room of a brick hospital built on top of a geological fault…

Issues that come up:
Atrtribution of data to providers