software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2003/002088.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] get_nickinfo like functions suggestion
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20get_nickinfo%20like%20functions%20suggestion&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="002091.html">
  11    <LINK REL="Next"  HREF="002089.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] get_nickinfo like functions suggestion</H1>
  15     <B>Finny Merrill</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20get_nickinfo%20like%20functions%20suggestion&In-Reply-To="
  17        TITLE="[IRCServices Coding] get_nickinfo like functions suggestion">griever at t2n.org
  18        </A><BR>
  19     <I>Tue Jun 24 14:59:10 PDT 2003</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="002091.html">[IRCServices Coding]  Building ircservices 5.0.20 on OpenBSD
  22  3.3    fails
  23 </A></li>
  24         <LI>Next message: <A HREF="002089.html">[IRCServices Coding] get_nickinfo like functions suggestion
  25 </A></li>
  26          <LI> <B>Messages sorted by:</B>
  27               <a href="date.html#2088">[ date ]</a>
  28               <a href="thread.html#2088">[ thread ]</a>
  29               <a href="subject.html#2088">[ subject ]</a>
  30               <a href="author.html#2088">[ author ]</a>
  31          </LI>
  32        </UL>
  33     <HR>
  34 <!--beginarticle-->
  35 <PRE>
  36 After discussing mysql module design it occurred to me that it would make
  37 designing a
  38 caching database module for mysql much easier if the get_ functions had
  39 analogs for
  40 read-only use.
  41
  42 I figure that if we create functions like get_readonly_nickinfo, it would
  43 allow
  44 for more efficient caching of data. The reasoning behind this is that
  45 procedures
  46 which modify a nick/channel/nickgroup need to have a more updated version
  47 of the
  48 data in order to figure out whether it can be modified the way it wants to.
  49
  50 On the other hand, many functions that only read from these pieces of data
  51 would not have to have the most recent version and could use the cached
  52 version
  53 since it would cause little harm to simply display out-of-date information
  54 to the user.
  55
  56 If we cached all pieces of data (including read-write), then it would
  57 happen
  58 that either the data in the database would be locked for too long and no
  59 outside
  60 program could ever modify it, or if we didn't lock the entries in the
  61 database,
  62 we would end up overwriting any changes another program made once we
  63 invalidated
  64 the cache.
  65
  66 So basically I propose creating database functions using names like
  67 get_readonly_nickinfo
  68 or get_readonly_chaninfo, which would be used by commands such as INFO,
  69 ACCESS LIST,
  70 AKICK LIST, AKILL LIST, and for determining access etc. The regular
  71 get_nickinfo etc
  72 functions would retain the same functionality for backwards compatibility
  73 and nothing
  74 would break.
  75
  76 These new get_readonly_* (or if you want, get_cache_*) would be implemented
  77 in modules
  78 that cache nick information in memory. In modules where either a)
  79 information is ALWAYS
  80 read from database on get_* or b) all information is always in memory, they
  81 would be
  82 synonyms for the regular get_* functions (i.e. in version4, they would be
  83 synonyms).
  84
  85 The info returned by these functions would generally not be modified (save
  86 for things
  87 that aren't saved to database such as the locked field) and wouldn't be
  88 passed to
  89 put_* functions. Also, it would be a bad idea to use the info returned from
  90 the
  91 readonly/cache functions to conditionally modify other data (example, you
  92 wouldn't
  93 use these functions to check someone's access so that they could change
  94 channel options,
  95 since another program could recently have removed them from the access list
  96 without
  97 us knowing it. It would be safe however to check someone's access to join
  98 the channel,
  99 use INVITE UNBAN OP etc, because that doesn't involve changing the
 100 ChannelInfo).
 101
 102 If I seem to be spouting gibberish, by all means ask me to clarify.
 103 </PRE>
 104
 105 <!--endarticle-->
 106     <HR>
 107     <P><UL>
 108         <!--threads-->
 109         <LI>Previous message: <A HREF="002091.html">[IRCServices Coding]  Building ircservices 5.0.20 on OpenBSD
 110  3.3    fails
 111 </A></li>
 112         <LI>Next message: <A HREF="002089.html">[IRCServices Coding] get_nickinfo like functions suggestion
 113 </A></li>
 114          <LI> <B>Messages sorted by:</B>
 115               <a href="date.html#2088">[ date ]</a>
 116               <a href="thread.html#2088">[ thread ]</a>
 117               <a href="subject.html#2088">[ subject ]</a>
 118               <a href="author.html#2088">[ author ]</a>
 119          </LI>
 120        </UL>
 121
 122 </body></html>