software/RELEASES/ircservices/achurch.org/services/lists/ircservices/2000/000846.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices] cheers. ideas.
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&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="000845.html">
  11    <LINK REL="Next"  HREF="000847.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices] cheers. ideas.</H1>
  15     <B>Andrew Church</B>
  16     <A HREF="mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To="
  17        TITLE="[IRCServices] cheers. ideas.">achurch at dragonfire.net
  18        </A><BR>
  19     <I>Wed Oct 11 16:10:46 PDT 2000</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="000845.html">[IRCServices] cheers. ideas.
  22 </A></li>
  23         <LI>Next message: <A HREF="000847.html">[IRCServices] cheers. ideas.
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#846">[ date ]</a>
  27               <a href="thread.html#846">[ thread ]</a>
  28               <a href="subject.html#846">[ subject ]</a>
  29               <a href="author.html#846">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>     Okay, my two cents:
  35
  36      I'll be the first to admit that the current Services database format
  37 is less than ideal.  When I originally designed Services, I designed it
  38 the network I had started a bit earlier, which at the time had at most
  39 20-30 simultaneous users.  Services can write a database of a few thousand
  40 nicks quickly enough not to matter, but up that by an order of magnitude
  41 and you'll start seeing lag just from writing the database.  Moreover, a
  42 single bit error in the wrong place and you lose the entire database (and
  43 apologies to anyone who's experienced this).
  44
  45      There's also the issue of accessing, and particularly altering, the
  46 databases from outside of Services.  Although access alone isn't really a
  47 problem--if you want to access the Services databases now, you can do it
  48 by borrowing the database loading code; listchans and listnicks work like
  49 that--altering the databases from outside of Services' control brings in
  50 all the classic problems of multithreaded applications--races, deadlocks,
  51 that sort of stuff.  Which isn't to say it can't be done, of course, but
  52 as Andrew Kempe commented, it'll take a good deal of work.  My personal
  53 thought is that it would be better done as a multi-step process: first
  54 implement some manner of sending Services certain commands from outside
  55 (e.g. register/drop a nick), iron out the problems there, then look at
  56 going to complete external read/write support.
  57
  58      As far as database format goes, I personally don't like either the
  59 XML or SQL options which have been presented so far.  While I agree that
  60 XML would make external viewing/editing of the databases easier and reduce
  61 the possibility of single-bit crashes, it would place even more strain on
  62 Services when updating the databases--not only do you have to write all
  63 the data to disk each time, you have to convert it all to ASCII and you
  64 have to add all sorts of formatting stuff, meaning both more CPU time and
  65 more disk space needed (I could easily see the database size tripling or
  66 worse).  As far as SQL goes, relying on an external program to be running
  67 in order to write data is just ugly; besides which, the delay in sending
  68 commands to the SQL server to read/write data would almost certainly be
  69 untenable.  (A 30-millisecond delay on an update request, for example, is
  70 fine if the requests are spread out among lots of clients; it's not fine
  71 if you have one program trying to do 50 updates a second.)  Besides which,
  72 there are probably a lot of people, myself included, who wouldn't want to
  73 use Services if it required installing an SQL server as well.
  74
  75      I personally see no reason why a proprietary format wouldn't work
  76 fine, as long as a library or some such was provided to allow other
  77 programs to access it.  In fact, given that the most important thing for
  78 Services is to be able to respond quickly to user requests, I think this
  79 is the best solution.  There really aren't any similar systems you can
  80 compare Services to (at least, none come to mind); if you want to talk
  81 about SQL, I would almost expect Services to act as an SQL _server_, not
  82 a client.
  83
  84      Actually, something like that may end up being a good solution after
  85 all.  There's no reason why external programs have to access the data
  86 _files_ for Services, just like database clients typically don't directly
  87 access the database server's data files; you can just have Services
  88 respond to requests through some channel--e.g. a control socket--and
  89 allow data access through that channel, like a database server.  The only
  90 need to access the files directly would be if they got corrupted, and
  91 with a good file structure design such occurrences (and the damage they
  92 caused) could be reduced to almost nil.
  93
  94      Comments?
  95
  96   --Andrew Church
  97     <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at dragonfire.net</A>
  98     <A HREF="http://achurch.dragonfire.net/">http://achurch.dragonfire.net/</A>
  99
 100 ---------------------------------------------------------------
 101 To unsubscribe, send email to <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org</A>
 102 with &quot;unsubscribe ircservices&quot; in the body, without the quotes.
 103
 104
 105 </PRE>
 106
 107 <!--endarticle-->
 108     <HR>
 109     <P><UL>
 110         <!--threads-->
 111         <LI>Previous message: <A HREF="000845.html">[IRCServices] cheers. ideas.
 112 </A></li>
 113         <LI>Next message: <A HREF="000847.html">[IRCServices] cheers. ideas.
 114 </A></li>
 115          <LI> <B>Messages sorted by:</B>
 116               <a href="date.html#846">[ date ]</a>
 117               <a href="thread.html#846">[ thread ]</a>
 118               <a href="subject.html#846">[ subject ]</a>
 119               <a href="author.html#846">[ author ]</a>
 120          </LI>
 121        </UL>
 122
 123 </body></html>