pcplantdb

[Sean Maley <semaley@yahoo.com>]

I still have to sift through some postings over the
last several years, so forgive me if I bring up
previously discussed issues.

Has it been considered to add a dimension to the
dataset, where any user can submit information for a
given plant data piece, but that information has a
rating attached.  The highest ratings for each piece
of information about a plant will be batched off to an
authoritative database, which the searches are
performed against.

This performs multiple purposes, besides who's writing
to use.  From a performance perspective, a relatively
small data set is used, but is also isolated from
exclusive locks (how a database coordinates incoming
modifications and prevents in flight changes causing
confusing query results).

The search engine could also be distributed across
several amateur connections to the internet, as a
community of hosts can be developed.  I see GANDI.NET
is the DNS server, so I'm not sure what it means for
ibiblio to provide a sub-domain.  Hosts wishing to
offer their bandwidth could register and an entry
could be made with GHANDIs DNS server.  Does GANDI.NET
allow automated DNS updates for subdomains?

Using this concept, databases could be batched to
cater to a specific bio-region, locale, or school of
thought.  Legal concerns can be in incorporated as
well for those needing to cater invasive species laws.
 In fact, a distributive model would resolve populous
bio-regions out voting other parts of the world and
cultures.  Have the authoritative sites contribute to
your operations overhead (they already start by taking
traffic off your hands), be responsible to maintain a
chosen level of service, contribute to deciding plant
description reputations, and store all the cruft you
don't want that you get by allowing everyone to add
their two cents (localized voting doesn't float up the
hierarchy chain).

XML is fine for capturing complex data sets, but isn't
always the answer.  With a properly defined data
model, and non text data, XML would be over kill.  I
wonder if the consumers of the data you will serve
have been defined.  If you plan on thin client apps
(Java/browser) being your only consumers, XML is fine.
 However, a more involved site might want to reduce
network traffic with a more traditional record based
feed (perhaps even compressed and over ssh
channels(scp)).

I'm working with a feed now using the LWP perl module.
 It's fairly simple.  A request string is constructed
and a one line data comes back or some error message. 
Data is communicated with Base64 encoding.  The data
could be either BINARY or TEXT.

Where I work, we communicate with our clients using
JMS and MQ (Tibco also popular).  There are really
simplistic schemes once you get used to them.  The
point being that there isn't really a standard for
communications exchange at this level because we are
at the point of implementation.  Setting up daemons is
easy too, but how to guarantee the message was
received has many implementations.

I prefer to SSL, but writing your own daemons has it's
advantages too.  The largest being that you can easily
configure a router to point TCP traffic to different
computers on your local network (much more scalable). 
On the other hand, most clients will have to tunnel
through http/https to have successful TCP traffic
(behind corporate firewall, etc).


Just some thoughts....


-Sean.



                
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250