[IRCServices] New services implementations & Updates?

[Andrew Kempe]

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.