On Friday 25 April 2003 09:19 am, nicos@itsa.ucsf.edu wrote: > [...]I enclose a tar.gz file with the > code so that you can have a look (don't know if it makes it through teh > mailing list, not a good idea to include a file, but....) Postings over 40k currently "pause" in the queue with a message to the list administrator, who can approve or reject it. I just approved it, naturally... I like this idea, though the individual format parsers might end up being classes themselves (and "enclosed" within the "wrapper" parser class). Of course, the really difficult part may be: > function autodetect () // figures out what seqfiletype this file is, Then again, that depends on how many different formats we want to be able to auto-detect. It may also be worthwhile to have "forced" format parsing enabled (e.g. the ability to directly call a particular parser without going through auto-detection, in case auto-detection proves problematic for some formats). > function parse_ANSI () (Shouldn't that be "ASN.1"?) I have FASTA and Clustal (.aln) parsers in the module code section already, if those are helpful at all. > The SQL stuff could be made self-contained in a similar fashion. I would > strongly advice though to stop using the direct MySQL calls but instead > immediately start using a database abstraction layer like adodb (my > favorite, I can help out with this one) or PEAR (might finally be usable). I would personally vote for PEAR, mainly to minimize dependencies on "non-default" components. Not that I would MANDATE it, even if I thought I could get away with it...