projects / irc.git / blame
| Commit | Line | Data |
|---|---|---|
| 3bd189cb JR |
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> |
| 2 | <HTML> | |
| 3 | <HEAD> | |
| 4 | <TITLE> [IRCServices] New services implementations & Updates? | |
| 5 | </TITLE> | |
| 6 | <LINK REL="Index" HREF="index.html" > | |
| 7 | <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20New%20services%20implementations%20%26%20Updates%3F&In-Reply-To="> | |
| 8 | <META NAME="robots" CONTENT="index,nofollow"> | |
| 9 | <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> | |
| 10 | <LINK REL="Previous" HREF="000564.html"> | |
| 11 | <LINK REL="Next" HREF="000565.html"> | |
| 12 | </HEAD> | |
| 13 | <BODY BGCOLOR="#ffffff"> | |
| 14 | <H1>[IRCServices] New services implementations & Updates?</H1> | |
| 15 | <B>Chris Knipe</B> | |
| 16 | <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20New%20services%20implementations%20%26%20Updates%3F&In-Reply-To=" | |
| 17 | TITLE="[IRCServices] New services implementations & Updates?">cgknipe at mweb.co.za | |
| 18 | </A><BR> | |
| 19 | <I>Sun Jun 4 05:21:18 PDT 2000</I> | |
| 20 | <P><UL> | |
| 21 | <LI>Previous message: <A HREF="000564.html">[IRCServices] New services implementations & Updates? | |
| 22 | </A></li> | |
| 23 | <LI>Next message: <A HREF="000565.html">[IRCServices] New services implementations & Updates? | |
| 24 | </A></li> | |
| 25 | <LI> <B>Messages sorted by:</B> | |
| 26 | <a href="date.html#566">[ date ]</a> | |
| 27 | <a href="thread.html#566">[ thread ]</a> | |
| 28 | <a href="subject.html#566">[ subject ]</a> | |
| 29 | <a href="author.html#566">[ author ]</a> | |
| 30 | </LI> | |
| 31 | </UL> | |
| 32 | <HR> | |
| 33 | <!--beginarticle--> | |
| 34 | <PRE>WAP Enabled NickServ ? :P *LOL* | |
| 35 | ||
| 36 | Chow | |
| 37 | Chris | |
| 38 | ||
| 39 | BTW, I'll be reading a bit deaper with more attention the replies received | |
| 40 | and perhaps come to a more "rpbust & complete" scenario and implementations. | |
| 41 | I must admit however, I did *not* lookup on the actual performance loss / | |
| 42 | gain on SQL related databases and such, it was just an idea pondering in my | |
| 43 | head... | |
| 44 | ||
| 45 | ||
| 46 | ----- Original Message ----- | |
| 47 | From: Andrew Kempe <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">andrewk at icon.co.za</A>> | |
| 48 | To: <<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at delirious.shadowfire.org</A>> | |
| 49 | Sent: 02 June 2000 09:39 | |
| 50 | Subject: RE: [IRCServices] New services implementations & Updates? | |
| 51 | ||
| 52 | ||
| 53 | ><i> This is a general reply to all the posts... | |
| 54 | </I>><i> | |
| 55 | </I>><i> I think an SQL server would be a more robust storage method than the flat | |
| 56 | </I>><i> files we use at present. I don't think we should replace them all | |
| 57 | </I>together. | |
| 58 | ><i> I would like an interface implemented in such a way that services writes | |
| 59 | </I>><i> (saves) data and reads (loads) data in a fixed manner that is independant | |
| 60 | </I>of | |
| 61 | ><i> the method used to actually store it. This would allow people to implement | |
| 62 | </I>a | |
| 63 | ><i> variety of different storage mechanisms that are invisible to services. In | |
| 64 | </I>><i> the end, services would be ignorant as to how or where it's data comes | |
| 65 | </I>from | |
| 66 | ><i> or goes to. This I hope will become a reality when modules are | |
| 67 | </I>implemented. | |
| 68 | ><i> | |
| 69 | </I>><i> Maybe someone wants to implement, dare I say it, an XML interface? :) | |
| 70 | </I>><i> | |
| 71 | </I>><i> Andrew | |
| 72 | </I>><i> | |
| 73 | </I>><i> > -----Original Message----- | |
| 74 | </I>><i> > From: <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">owner-ircservices at delirious.shadowfire.org</A> | |
| 75 | </I>><i> > [mailto:<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">owner-ircservices at delirious.shadowfire.org</A>]On Behalf Of Jonathan | |
| 76 | </I>><i> > Morton | |
| 77 | </I>><i> > Sent: 30 May 2000 03:59 | |
| 78 | </I>><i> > To: <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at delirious.shadowfire.org</A> | |
| 79 | </I>><i> > Subject: Re: [IRCServices] New services implementations & Updates? | |
| 80 | </I>><i> > | |
| 81 | </I>><i> > | |
| 82 | </I>><i> > >The idea of using SQL sounds good at first. But these services | |
| 83 | </I>><i> > are generally | |
| 84 | </I>><i> > >used by small or medium IRC networks all over the world. Some of | |
| 85 | </I>><i> > them have | |
| 86 | </I>><i> > >low configurations and smaller bandwidths. These implementation | |
| 87 | </I>><i> > would need | |
| 88 | </I>><i> > >an additional SQL server as Andy pointed out. Also having | |
| 89 | </I>><i> > statistics on web | |
| 90 | </I>><i> > >would result to another performance decrease. Security is another | |
| 91 | </I>point. | |
| 92 | ><i> > | |
| 93 | </I>><i> > Might I suggest a compromise, which would allow the increased Web | |
| 94 | </I>><i> > functionality while retaining the simplicity of the existing system: | |
| 95 | </I>><i> > | |
| 96 | </I>><i> > When a change is made to the Services database, export that change to an | |
| 97 | </I>><i> > OPTIONAL SQL database, which may or may not be on a different | |
| 98 | </I>><i> > server. Then | |
| 99 | </I>><i> > the Web-functionality can be stuck on top of that SQL database as | |
| 100 | </I>><i> > required. | |
| 101 | </I>><i> > If changes need to be made in the reverse direction too, then a | |
| 102 | </I>mechanism | |
| 103 | ><i> > for re-importing changes should be made available. | |
| 104 | </I>><i> > | |
| 105 | </I>><i> > I think they key issue here is to avoid changing the basic | |
| 106 | </I>implementation | |
| 107 | ><i> > where possible, but provide hooks so that bigger functionality | |
| 108 | </I>><i> > can be added | |
| 109 | </I>><i> > as and when it is desired, and can be set up by the server owners. I | |
| 110 | </I>><i> > really like the way Services can be set up with minimal effort - I | |
| 111 | </I>gather | |
| 112 | ><i> > setting up SQL is rather less trivial. By making SQL optional, | |
| 113 | </I>><i> > we can grab | |
| 114 | </I>><i> > that extra functionality for those that want it (we probably don't, on | |
| 115 | </I>our | |
| 116 | ><i> > small server) but keep it simple for those that don't. As for security, | |
| 117 | </I>><i> > that would need to be addressed by whoever decided to activate the SQL | |
| 118 | </I>><i> > setup - basic functionality should not be affected. | |
| 119 | </I>><i> > | |
| 120 | </I>><i> > -------------------------------------------------------------- | |
| 121 | </I>><i> > from: Jonathan "Chromatix" Morton | |
| 122 | </I>><i> > mail: <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">chromi at cyberspace.org</A> (not for attachments) | |
| 123 | </I>><i> > uni-mail: <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">j.d.morton at lancaster.ac.uk</A> | |
| 124 | </I>><i> > | |
| 125 | </I>><i> > The key to knowledge is not to rely on people to teach you it. | |
| 126 | </I>><i> > -------------------------------------------------------------- | |
| 127 | </I>><i> > Contributing to the VNC Project - <A HREF="<A HREF="http://www.uk.research.att.com/vnc/"">http://www.uk.research.att.com/vnc/"</A>><A HREF="http://www.uk.research.att.com/vnc/</A">http://www.uk.research.att.com/vnc/</A</A>> | |
| 128 | </I>><i> > Macintosh VNCserver v3.3.2 beta2.3 now posted at: | |
| 129 | </I>><i> > <A HREF="<A HREF="http://chromatix.autistics.org/vnc/"">http://chromatix.autistics.org/vnc/"</A>><A HREF="http://chromatix.autistics.org/vnc/</A">http://chromatix.autistics.org/vnc/</A</A>> | |
| 130 | </I>><i> > | |
| 131 | </I>><i> > | |
| 132 | </I>><i> > | |
| 133 | </I>><i> > --------------------------------------------------------------- | |
| 134 | </I>><i> > To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A> | |
| 135 | </I>><i> > with "unsubscribe ircservices" in the body, without the quotes. | |
| 136 | </I>><i> > | |
| 137 | </I>><i> | |
| 138 | </I>><i> | |
| 139 | </I>><i> --------------------------------------------------------------- | |
| 140 | </I>><i> To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A> | |
| 141 | </I>><i> with "unsubscribe ircservices" in the body, without the quotes. | |
| 142 | </I> | |
| 143 | ||
| 144 | --------------------------------------------------------------- | |
| 145 | To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A> | |
| 146 | with "unsubscribe ircservices" in the body, without the quotes. | |
| 147 | ||
| 148 | ||
| 149 | </PRE> | |
| 150 | ||
| 151 | <!--endarticle--> | |
| 152 | <HR> | |
| 153 | <P><UL> | |
| 154 | <!--threads--> | |
| 155 | <LI>Previous message: <A HREF="000564.html">[IRCServices] New services implementations & Updates? | |
| 156 | </A></li> | |
| 157 | <LI>Next message: <A HREF="000565.html">[IRCServices] New services implementations & Updates? | |
| 158 | </A></li> | |
| 159 | <LI> <B>Messages sorted by:</B> | |
| 160 | <a href="date.html#566">[ date ]</a> | |
| 161 | <a href="thread.html#566">[ thread ]</a> | |
| 162 | <a href="subject.html#566">[ subject ]</a> | |
| 163 | <a href="author.html#566">[ author ]</a> | |
| 164 | </LI> | |
| 165 | </UL> | |
| 166 | ||
| 167 | </body></html> |