[DAS] LDAS vs Dazzle

[jfreeman]

Hello all,

Thanks for the quick response!

Ewan Birney wrote:
> 
> Just to make sure people don't think something weird is going on:
> 
> (a) Ensembl's "assembly" is (currently) a particular UCSC golden path and
> soon will be one of the NCBI golden paths. Ensembl doesn't make assemblies
> - we just choose one to use.

I never meant to imply that Ensembl's choice of any of the golden paths
in the past or present or future was or is or will be suspect, from my
last note.  I was, badly, making the point that if you decide to map
your data onto any one of them the cost of doing so leads you to want to
pick one, as Ensembl does, rather than map to them all.  That is the
source for a natural lock-in for anyone doing the mapping, if you would
like enjoy the utility of the Ensembl package then you go with what
Ensembl chose when you do your mapping.  The choice of a particular
golden path is Ensembl's prerogative as you mention, but the rationale
for the change is not clearly understood, given your cost of remapping
your data, and my cost of doing the same.  If you have the time to
educate me, I would like to understand what leads to the Ensembl group
choose a particular golden path, and this will help me explain the value
of the system, given the remapping costs, internally, and might be of
some use to others on this list.
 
> (b) As many people have pointed out, Dazzle is not bound to Ensembl
> inherently - it is just that there is an easy-to-use plug in for Ensembl
> data sources - ie, Dazzle is both generic to other data sources and
> specific to Ensembl.

Agreed.  The available documentation about Dazzle and its ease of use,
not the utility of Dazzle itself was what I was pointing out to a new
person making the decision.  The utility of Dazzle is shown at:
http://servlet.sanger.ac.uk:8080/das/.  It's value to the person who is
installing it locally regardless of the programming experience debugging
the install documentation vs. the program itself was what I was trying
to show.  Ensembl's install documentation does not seem to require great
deal of prior knowledge about being a java programmer vs. a perl
programmer, or a mysql expert, and is a gold standard from my point of
view for documentation on installing a complex open source system
locally.  The Dazzle install documentation, is what causes the perl vs.
java split, in my opinion, not the nature of the application itself,
solve the first problem and the second problem goes away.  If it is the
case that Dazzle install documentation is ok, if you have been
developing servlet code in Java under Mandrake, if not start developing
some servlet code in Java in Mandrake, and you will be fine, that is
fine, but I don't know if it is necessary.
 
> (c) I suspect the general feeling of "it is easier to set up a LDAS
> server" is probably right, mainly because Lincoln designs things with an
> eye to ease-of-use whereas Thomas designs thing with an eye to
> extensibility.

Agreed.  This might be "Worse is better" vs. "The Right Thing".

See: http://www.jwz.org/doc/worse-is-better.html 

> (d) I would look at both and go with the one which you feel more
> comfortable with. I'm pretty sure that means whether you are a Java
> programmer (Dazzle) or a Perl programmer (LDAS)
> 
> e
> 

If (d) applies to Ensembl local installs and Dazzle local installs, then
I agree, if not then the problem seems to be in the Dazzle install
documentation only.

I am loath to make these statements if they are viewed as looking a gift
horse in the mouth, I hope to be constructive and help out the process
and by extension the community.  The fact that these systems are
available at all is a great service to the community, both for public
and private groups doing bioinformatics.

Thanks again for your help,

Jim Freeman
 _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das