Re: Some sugestions.

Neil Muller (neil nospam at zeta.mth.uct.ac.za)
Thu, 11 Mar 1999 18:36:55 +0200

On Thu, Mar 11, 1999 at 08:03:26AM -0700, Travis Tabbal wrote:
> Storage: RDBMS. Any type will do if it supports our basic layout. I would
> recomend we use basic SQL types for the data fields to provide maximum
> compatibilty. Tables and other data format specs to be determined.
>
> If not, how about a nightly (or other time period) diff file to be sent via
> HTTP? If the records had a timestamp it would be easy to write a SQL query
> for all submissions within a certain timeframe to be exported to a diff
> database that could be compressed and made available for the remote
> databases to download and merge.

If we intend making this truely international (as any good free software project
should be) there will be problems with a fixed time update. Updating the
database is probably something you want to do at low usage times. Since this
will very depending on the location of the server, a timestamp based method
would be preferred here.

> Servers looking for an update would just
> connect and request. Some type of mirror structure would be nice. The
> primary site would only allow certain sites to request the new data, thus
> keeping server load down.

---- Quite a lot cut -----

> This does leave a single point of failure, the root server. We should
> consider options to cover for this. Some kind of failover method maybe? Or
> we could just pick someone with nice stable servers with a hot spare and
> hope for the best. The system itself could function for quite some time
> without the root server before problems got out of hand.

We should be careful with any plan requiring a root server. If we design for
some cannonical reference database, far to much authority is placed in the hands
of that maintainers of that machine. While it should be possible to design the
system so that changing over to a new root server is as painless as possible,
the need to do so would already be considerable inconvience.

The alternative to to avoid having an authoritive root server at all and
take the decentralised route (as done in news distribution, et al.) The
major objections to this method is the slow propagation time for new additions
and consequently the much increased risk of multiple entries (which may not
neccessarily be a bad thing, especially if some voting strategy is used to
decide on the correct information.)

> The nice thing is that client access to
> the DB doesn't need much of anything. Just basic HTTP, which most CDDB
> capable programs allready have. This will help gain converts to the new
> format, it's easy to do with the tools they allready have. Remember
> people, KISS! (Keep It Simple, Stupid)
Very true.

> Travis Tabbal
> bigboss nospam at xmission.com
>

-- 
Neil Muller
neil nospam at zeta.mth.uct.ac.za