[Biophp-dev] Release criteria

[S Clark]

On Thursday 08 May 2003 12:07 pm, Serge Gregorio wrote:
> >Possibly - I wouldn't bother with a "set" release date, personally.
> >Instead - what capabilities should make up the next "formal release"
> >(i.e. "it's ready to release when THESE capabilities are implemented
> >and tested")?
>
> Oh okay... any suggestions (about release criteria)?

How about...

Code Style Issues:
Format to PEAR standards
Implement interface methods for all public attributes
Figure out where EUtils and NCBI Blast modules will fit in the scheme of
things.

Capabilities:
(stuff I'm partly or wholly responsible for at the moment)
All existing filetype parsers adjusted to new scheme (very nearly done 
already)

seq_factory private "translation" layer in place (doesn't need to be
very complex at this point, but should actually "exist" and be operational)

NCBI Blast module usable

ESearch working (done, other than format adjustments for PEAR standards)

ESummary working (done, other than format adjustments)

EFetch modules for at least 2 (?) of the Entrez databases.

(other people's work)
Who knows? :-)
Suggestions?

> As for the opening/closing the file stream issue, I guess
> a safe compromise would be to give the user the choice of
> whether the stream is perpetually open until explicitly
> closed, or if it's closed automatically after reading the
> data.  Again, it depends on how the user uses the parser
> class.

I think what we've got going now essentially does this - the
filetype parsers will leave the source "open" if it was open to
begin with (i.e. if a filehandle was passed) or close it if the
source is an unopened filename.  

We COULD add a "doNotCloseSource()" method (or some more intuitive
name :-) ) call and method for returning the still-open filehandle
to the caller, but I don't know if it'll be worth the extra complexity.
Thoughts?