[IRCServices] New services implementations & Updates?

[Chris Knipe]

WAP Enabled NickServ ? :P *LOL*

Chow
Chris

BTW, I'll be reading a bit deaper with more attention the replies received
and perhaps come to a more "rpbust & complete" scenario and implementations.
I must admit however, I did *not* lookup on the actual performance loss /
gain on SQL related databases and such, it was just an idea pondering in my
head...


----- Original Message -----
From: Andrew Kempe <andrewk at icon.co.za>
To: <ircservices at delirious.shadowfire.org>
Sent: 02 June 2000 09:39
Subject: RE: [IRCServices] New services implementations & Updates?


> This is a general reply to all the posts...
>
> I think an SQL server would be a more robust storage method than the flat
> files we use at present. I don't think we should replace them all
together.
> I would like an interface implemented in such a way that services writes
> (saves) data and reads (loads) data in a fixed manner that is independant
of
> the method used to actually store it. This would allow people to implement
a
> variety of different storage mechanisms that are invisible to services. In
> the end, services would be ignorant as to how or where it's data comes
from
> or goes to. This I hope will become a reality when modules are
implemented.
>
> Maybe someone wants to implement, dare I say it, an XML interface? :)
>
> Andrew
>
> > -----Original Message-----
> > From: owner-ircservices at delirious.shadowfire.org
> > [mailto:owner-ircservices at delirious.shadowfire.org]On Behalf Of Jonathan
> > Morton
> > Sent: 30 May 2000 03:59
> > To: ircservices at delirious.shadowfire.org
> > Subject: Re: [IRCServices] New services implementations & Updates?
> >
> >
> > >The idea of using SQL sounds good at first. But these services
> > are generally
> > >used by small or medium IRC networks all over the world. Some of
> > them have
> > >low configurations and smaller bandwidths. These implementation
> > would need
> > >an additional SQL server as Andy pointed out. Also having
> > statistics on web
> > >would result to another performance decrease. Security is another
point.
> >
> > Might I suggest a compromise, which would allow the increased Web
> > functionality while retaining the simplicity of the existing system:
> >
> > When a change is made to the Services database, export that change to an
> > OPTIONAL SQL database, which may or may not be on a different
> > server.  Then
> > the Web-functionality can be stuck on top of that SQL database as
> > required.
> > If changes need to be made in the reverse direction too, then a
mechanism
> > for re-importing changes should be made available.
> >
> > I think they key issue here is to avoid changing the basic
implementation
> > where possible, but provide hooks so that bigger functionality
> > can be added
> > as and when it is desired, and can be set up by the server owners.  I
> > really like the way Services can be set up with minimal effort - I
gather
> > setting up SQL is rather less trivial.  By making SQL optional,
> > we can grab
> > that extra functionality for those that want it (we probably don't, on
our
> > small server) but keep it simple for those that don't.  As for security,
> > that would need to be addressed by whoever decided to activate the SQL
> > setup - basic functionality should not be affected.
> >
> > --------------------------------------------------------------
> > from:     Jonathan "Chromatix" Morton
> > mail:     chromi at cyberspace.org  (not for attachments)
> > uni-mail: j.d.morton at lancaster.ac.uk
> >
> > The key to knowledge is not to rely on people to teach you it.
> > --------------------------------------------------------------
> > Contributing to the VNC Project - <A  HREF="http://www.uk.research.att.com/vnc/">http://www.uk.research.att.com/vnc/</A>
> > Macintosh VNCserver v3.3.2 beta2.3 now posted at:
> > <A  HREF="http://chromatix.autistics.org/vnc/">http://chromatix.autistics.org/vnc/</A>
> >
> >
> >
> > ---------------------------------------------------------------
> > To unsubscribe, send email to majordomo at ender.shadowfire.org
> > with "unsubscribe ircservices" in the body, without the quotes.
> >
>
>
> ---------------------------------------------------------------
> To unsubscribe, send email to majordomo at ender.shadowfire.org
> with "unsubscribe ircservices" in the body, without the quotes.


---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.