bug-gne
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnupedia] From the "Department of Wacky Ideas"


From: Tom Chance
Subject: Re: [Bug-gnupedia] From the "Department of Wacky Ideas"
Date: Sat, 20 Jan 2001 16:10:47 -0800 (PST)

> I'm not sure how "modern" a solution this is
> though: why should
> the general public have to go hunting for working
> mirrors?). 
They wouldn't. There are plenty of easy ways to make
it very easy for the user. They range from a simple
"Where are you in the world?" page, which is done by
cgi and checks available mirrors around the world. Or
even a javascript thing if we wanted to be truly evil!
:)


> The location of content doesn't affect database
> searches: the location
> of the indexes does. 
It depends how you set up your database. If you had
all the articles in individual XML files, your
solution would work great. But I would have thought
we'd want to go for something more advanced like
mySQL, in which case many different databases would be
a problem.
 
> In a word: performance.  You're going to generate a
> lot of traffic to a
> few locations, and you'll need some beefy servers to
> support searches
> on the database. Large coporations spend a lot of
> money on
> high-performance machines to handle their database
> traffic, I don't see
> how we would be any different. After all, we don't
> just respond with
> the index information a la google, we supply content
> too.
Beefy servers are easy to do really. Lets face it
we're not looking at thousands of hits at a time,
certainly not in the next one or two years anyway. All
you need is an HTTP server, an SQL box, and a bank of
10 or so crappy old machines running Perl. Wouldn't
cost all that much, and would be just as good as a
distributed network. Also a lot more professional. I
just get the feeling this network of baby servers
would turn into the web very quickly, as it would need
a lot of careful maintaining. 

> That said, of course it can be done with less h/w
> than commercial
> outfits, we don't have their performance criteria.
> Public projects like
> ours tend to produce better, tighter code too... But
> it's still going
> to need a lot more hardware & money than the "wacky"
> approach. On the
> main server and at each mirror too.
I'm sure we could get the funding. For now we'd need a
very small setup of say 3 or 4 computers (not hard to
get) and basic permanent connection. In the future, if
we do grow big, we'll attract sponsors easily and will
be able to expand the thing without converting our
structure and all our databases etc, to be as big as
we want!

> > The central
> > server would be, I assume, in the US, and even
> their
> > control-freak government can't shut down something
> > like this.
> 
> Actually gthe way things are going, the US may soon
> be the only place
> they can't shut things down. 
I'm not sure I agree (admittedly this is politics not
Gnupedia stuff lol) seeing as the US has some of the
most stringent copyright & patent laws... only France
so far has buckled to pressure on freedom of web
sites, and that was with Yahoo. There have been the
odd sites taken down for being anti-governmental
elsewhere in Europe, but I'd still say Europe is a lot
more "free" in the good ways (information, press,
expression) than the US.


And anyways, I'm sorry I was a little negative Bob! I
was tired and getting demoralised by the amount of XML
people, and the fact that nobody seems to recognise
the limitations of it. I just think it would be a huge
mistake to not look forward to what would happen if
this were to become big. If we go down the XML root, I
get this feeling in a year or two's time we'll curse
ourselves for the amount of needless work we made
ourselves. Why build a castle on sand when it can be
built on premium SQL-grade concrete foundations?

Tom Chance

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]