In article <1995Mar19.101420.1552 at comp.bioz.unibas.ch>, doelz at comp.bioz.unibas.ch (Reinhard Doelz) writes:
>Foteos Macrides (macrides at sci.wfeb.edu) wrote:
>>: I think this is simply a matter of at present inadequate familiarity
>: with WWW software and principles, coupled to a real threat of harmful
>: copyright infringement: If an http server executes a GCG program via a
>: CGI script, it is not enough for the server to be on a system with a GCG
>: license. The server should apply at least Level 1 (host check) protection
>: to ensure that the client also is encompassed by the site's license.
>: Otherwise, a few http servers could have licenses, and service the whole
>: world, driving GCG out of business.
>>This is nicely summarizing this thread that WWW, despite being a great tool,
>does not solve all problems and does not provide all desired capabilities;
>which shows that you need our HASSLE software to run GCG remotely, not http
>as advertized :-)
Yes. It's important to keep in mind that http and gopher servers
are for distributed *information* sharing, and though they can invoke
scripts to access databases and format the extracted information before
sending it to the client for screen display, they are not inherently
designed as interfaces for intensive computing *services*. If you want a
a coherent, user-friendly interface to a comprehensive suite of computation
intense programs such as the GCG package, you certainly will do better
writing one specifically for that suite. The distributed information
sharing protocols are context free, and many of the things you'd want
the interface to do require context (as well as file import, or pointer,
capabilities that are often less then ideal, or absent, in WWW or gopher
>this sounds less dangerous than it reads, because, as mentioned some time
>earlier in this thread, those few servers really had a hard time. As far
>as services like FASTA or similar go, (1) there is a natural tendency to
>clog up a server once it becomes popular, making its use less attractive,
>and (2) the software to run at the server would not necessarily need to
>be GCG -type, but maybe the 'straight' version which runs possibly faster
>as well as a public domain product. EBI/EMBLs server runs FASTA since ages
>without representing a huge thread for GCG, for example.
FASTA and BLAST are included in the GCG package, but they are
not it's essense. It's essense is its comprensiveness and coherence,
and its support services. As you've stressed before yourself, the
labor and associated costs involved in putting together and supporting
a comparably comprensive program suite locally, based on public domain
and open copyrighted programs, can in the long run be far more expensive,
particularly if the users are not computer sophistocated and can be
confused by this program's way of doing things versus another's. The
public access FASTA and BLAST servers are worthwhile, very much appreciated,
and not worrisome competition for the comprehensive commercial packages
>After all, why should you expect that service providers want to bless the
>world for free? Soon or later all our funding agencies might want to see
>return value or proofs that the facilities provided are serving the purpose.
>At the current budget situation, I don't see any public funding agency willing
>to provide world-wide service unless a advertising, user feedback, quality
>improvement or other benefit arises. Just popularity for the service provider
>is not a source for good revenue in public funding. If you feel different,
>I'll mail you our bank account number immediately :-) or take Dave's to
BIOSCI (news) is another distributed information sharing system,
not a computational service (Dave simply happens to be an IG employee as
well as the BIOSCI manager.).
>I think all discussion can be summarized in 'yes, we want free access to the
>manual for all' but the implementation model is fairly undefined - do we
>want public advertisement on the net ? Manuals could easily be interpreted
>as such advertisement as you can't make real use of it unless you have (access
>to) the software, too. Have a purchase order form codistributed?
>The licensing is worth considering, and you will need to individually
>negotiate with the provider. This has happened in the past, so isn't this a
>reasonable way to proceed in the future, too?
>>If really someone insists on running GCG on a locally based system new tools
>will arise in the future to provide this type of access. No need to worry
>that the icurrent WWW type of mechanism will be of continuity for very long-
>many of us are in the process of developing new tools, access paths and
>more. Stay patient, and time will come.
Again, I think it's important to draw distinctions between
distributed information sharing versus computational services, even
though computers are mediating both, and there's a grey area between
the two. People are not so much looking for "free access" to the
GCG help and manuals, as for maximally convenient access, and the
http-served help and manual sections *are* fast and convenient,
because that's the kind to thing the protocol is designed to do well.
It's true that having fetched a help or manual section, the user could
print it, but why would s/he bother, when with a few keystrokes and click
on a hotlist/bookmark link s/he could fetch and display it again, instead
of having to hunt for the hard copy wherever it was filed?!?! The
"advertising" perspective may by worth thinging about, but not for
very long 8-). For the most part, such "advertising" is preaching to
the already converted.
Foteos Macrides Worcester Foundation for Experimental Biology
MACRIDES at SCI.WFEB.EDU 222 Maple Avenue, Shrewsbury, MA 01545