[Biojava-l] Re: Experimental DAS 1.900 implementation / biodas code on our servers

[chris dagdigian]

Thanks for clarifying that Jason!

Jason is dead right. A long time ago we decided for security reasons 
(nobody trusts cvs pserver that much..) that all anonymous cvs access 
would have to be via a standalone box. Hence the cvs.bio{whatever}.org 
hostnames.

Regarding getting Biodas.org sorted -- I've done as much as I can with 
GID/account creation, apache vhosts and whatnot. Lincoln has already 
started cvs init'ing codebase repositories. I'm waiting now for the DNS 
stuff to happen. I can't really set up mailing lists, cvs.biodas.org or 
even the web cvs stuff without working DNS...well actually I could set 
them up but it would not be all that useful :) I understand via Lincoln 
that DNS changes are in progres.

Regards,
Chris



Jason Stajich wrote:

> For clarification.
> 
> cvs.bio{*}.org is a replication of bio{*}.org not the same machine.  We
> rsync the cvs repositories on cvs.bio{*} from bio{*} machine every 2
> hours.
> 
> So:
> cvs.biodas.org is where anonymous cvs will live, devs who need write
> access to the das cvs repository will need accounts on the biodas.org,
> those just checking out anonymous versions can obtain via cvs.biodas.org
> or through webcvs for browsing.  see http://cvs.bioperl.org.
> 
> (Chris can you make sure Lincoln's new biodas repositories
>  are added to the rsync list when you setup webcvs)
> 
> * = (perl|java|python|corba|xml|das) 
> 
> On Tue, 12 Jun 2001, Lincoln Stein wrote:
> 
> 
>>Hi Thomas, et al.,
>>
>>I've moved the biodas repository to cvs.biodas.org (physically the
>>same machine as biojava.org, I think).  Shall we move the CVS
>>repository there and integrate the biodas.org and biojava.org/das web
>>pages? (I'll do the stitching together).
>>
>>Lincoln
>>
>>Thomas Down writes:
>> > Hi...
>> > 
>> > I've started working on an experimental Java implementation of
>> > the DAS 1.900 proposal, so that we've got something to play
>> > with as the specification develops.  At the moment there's
>> > just a Sequence service (vaguely equivalent to refererence
>> > servers in DAS1).  I've got most of the pieces of a Features
>> > service, and should be able to check that in in the next day
>> > or so.
>> > 
>> > For anyone who's interested in tracking development, there's
>> > code in the BioJava CVS repository (http://cvs.biojava.org/
>> > for more info).  Checkout the module `xdas'.
>> > 
>> > What you get:
>> > 
>> >   - Prototype DAS sequence service
>> > 
>> >   - The SOAP toolkit it relies on.
>> > 
>> >   - An obligatory stock-quote demo ;)
>> > 
>> > To preempt the inevitable question, yes I have looked at other
>> > SOAP toolkits (especially the IBM/Apache one).  While they're good
>> > a lot of the time, they tend to use DOM to represent the SOAP messages
>> > in-memory.  I know from past experience that this really isn't a good
>> > idea where DAS is concerned -- sometimes you want to shift quite
>> > serious amounts of data around (especially feature-tables), and I've
>> > seen OutOfMemoryErrors (as well as poor performance) when the BioJava
>> > DAS client was using a DOM based solution.
>> > 
>> > The new SOAP toolkit is based on S[t]AX event-based XML parsing,
>> > so that should help scalability.
>> > 
>> > 
>> > I'd be interested to hear any comments about this code...
>> > 
>> > 
>> >    Thomas.
>>

>