Forums

* Michael Hucka <mhucka@caltech.edu> [2009-05-18 21:18] writes:
> In the recent libSBML survey, people frequently asked for a
> pure Java implementation. We're considering it. Developing
> it would be a non-trivial undertaking and have serious
> maintenance implications, for example because we would have
> two separate code bases to deal with. We have some ideas
> for how to avoid rewriting some of the more complex parts,

Whew, that sounds like a nightmare. It also doesn't sound very
sustainable in the long run--my prediction would be that after lurching
along as a hybrid for a few years, you'd eventually collapse back into one
codebase. If the majority of people wish libSBML was written in Java, you
might consider switching to Java instead of C++, which would make me sad,
but still sounds better to me than trying to be a hybrid.

You also have to consider the speed at which your team can provide
updates. I can't say what the survey responders would prefer, but I know
that if I had to make a choice between more frequent updates and a code
base written in my favorite language, I'd choose more frequent updates.
This would apply to a language switch as well as a switch to being a
hybrid, the only difference being that a language switch might
theoretically pay off in the future if it became easier for your team to
code in the new language, while a switch to being a hybrid would not only
eat up time now, it would continue to eat up time in the future, and would
therefore never pay off.

The cost/benefit analysis is looking pretty grim from this end.

> 1) When libSBML 5 is introduced with its modular extension
> mechanism to support SBML Level 3 packages, and we
> request other developers to provide implementations of L3
> packages, would people have to provide *both* a regular
> implementation (including a SWIG interface definition for
> Java) and a pure Java implementation? If not, then who
> will implement the other version?

If you up the requirements, you will get less help. So I think that apart
from asking nicely, if you go to a hybrid system you are commiting your
team to implementing the other version of the submitted module. IIRC, you
are already basically committing your team to maintain supplied packages,
right? So this might not be quite as bad as it might otherwise be. But
again, it's a huge cost in terms of time. If you were going to have to
write the extension yourself, by going hybrid you just killed any benefit
you were hoping to receive by asking for outside development support.
There's also either an added lag time between one version and the next
coming out, or an added lag time of anything coming out if you want to
release both at once.

> 2) Level 3 package support should come with validation code,
> so that libSBML can do validation on models that include
> the given L3 package. The validator built into libSBML
> will likely be modularized to support extensions for L3
> packages. Will developers who implement support for L3
> packages also have to provide validator code in *both*
> C/C++ and pure Java form, if a pure Java version of
> libSBML exists?

Same answer here--you can't expect to receive both versions of the code,
though you can ask. Which means you're committing your team to doing it.

My vote (which is worth the pixels its printed on (which if it was a
usenet post would be hundreds if not thousands of dollars!)) is:

1) A single-language codebase in my favorite language
2) A single-language codebase in a different language, with bindings for
mine.
3) A hybrid double codebase which includes my favorite language.

-Lucian
____________________________________________________________
To manage your libsbml-development list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/libsbml-development

For a web interface to the libsbml-development mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the libsbml-development list,
contact sbml-team@caltech.edu