1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices Coding] get_nickinfo like functions suggestion
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=oprrakowbo3wwnu9%40mail-hub.optonline.net">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"002088.html">
11 <LINK REL=
"Next" HREF=
"002093.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices Coding] get_nickinfo like functions suggestion
</H1>
16 <A HREF=
"mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20get_nickinfo%20like%20functions%20suggestion&In-Reply-To=oprrakowbo3wwnu9%40mail-hub.optonline.net"
17 TITLE=
"[IRCServices Coding] get_nickinfo like functions suggestion">achurch at achurch.org
19 <I>Wed Jun
25 10:
35:
53 PDT
2003</I>
21 <LI>Previous message:
<A HREF=
"002088.html">[IRCServices Coding] get_nickinfo like functions suggestion
23 <LI>Next message:
<A HREF=
"002093.html">[IRCServices Coding] get_nickinfo like functions suggestion
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#2089">[ date ]
</a>
27 <a href=
"thread.html#2089">[ thread ]
</a>
28 <a href=
"subject.html#2089">[ subject ]
</a>
29 <a href=
"author.html#2089">[ author ]
</a>
34 <PRE> Easy counterexample: /os akill add luser@*.example.com (where it
35 would definitely _not_ be proper to use out-of-date data)
38 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org
</A>
39 <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
42 </I>><i>After discussing mysql module design it occurred to me that it would make
43 </I>><i>designing a
44 </I>><i>caching database module for mysql much easier if the get_ functions had
45 </I>><i>analogs for
46 </I>><i>read-only use.
48 </I>><i>I figure that if we create functions like get_readonly_nickinfo, it would
50 </I>><i>for more efficient caching of data. The reasoning behind this is that
52 </I>><i>which modify a nick/channel/nickgroup need to have a more updated version
54 </I>><i>data in order to figure out whether it can be modified the way it wants to.
56 </I>><i>On the other hand, many functions that only read from these pieces of data
57 </I>><i>would not have to have the most recent version and could use the cached
59 </I>><i>since it would cause little harm to simply display out-of-date information
60 </I>><i>to the user.
62 </I>><i>If we cached all pieces of data (including read-write), then it would
64 </I>><i>that either the data in the database would be locked for too long and no
66 </I>><i>program could ever modify it, or if we didn't lock the entries in the
68 </I>><i>we would end up overwriting any changes another program made once we
69 </I>><i>invalidated
72 </I>><i>So basically I propose creating database functions using names like
73 </I>><i>get_readonly_nickinfo
74 </I>><i>or get_readonly_chaninfo, which would be used by commands such as INFO,
75 </I>><i>ACCESS LIST,
76 </I>><i>AKICK LIST, AKILL LIST, and for determining access etc. The regular
77 </I>><i>get_nickinfo etc
78 </I>><i>functions would retain the same functionality for backwards compatibility
79 </I>><i>and nothing
80 </I>><i>would break.
82 </I>><i>These new get_readonly_* (or if you want, get_cache_*) would be implemented
84 </I>><i>that cache nick information in memory. In modules where either a)
85 </I>><i>information is ALWAYS
86 </I>><i>read from database on get_* or b) all information is always in memory, they
88 </I>><i>synonyms for the regular get_* functions (i.e. in version4, they would be
91 </I>><i>The info returned by these functions would generally not be modified (save
93 </I>><i>that aren't saved to database such as the locked field) and wouldn't be
95 </I>><i>put_* functions. Also, it would be a bad idea to use the info returned from
97 </I>><i>readonly/cache functions to conditionally modify other data (example, you
99 </I>><i>use these functions to check someone's access so that they could change
100 </I>><i>channel options,
101 </I>><i>since another program could recently have removed them from the access list
103 </I>><i>us knowing it. It would be safe however to check someone's access to join
104 </I>><i>the channel,
105 </I>><i>use INVITE UNBAN OP etc, because that doesn't involve changing the
106 </I>><i>ChannelInfo).
108 </I>><i>If I seem to be spouting gibberish, by all means ask me to clarify.
109 </I>><i>------------------------------------------------------------------
110 </I>><i>To unsubscribe or change your subscription options, visit:
111 </I>><i><A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
</A>
118 <LI>Previous message:
<A HREF=
"002088.html">[IRCServices Coding] get_nickinfo like functions suggestion
120 <LI>Next message:
<A HREF=
"002093.html">[IRCServices Coding] get_nickinfo like functions suggestion
122 <LI> <B>Messages sorted by:
</B>
123 <a href=
"date.html#2089">[ date ]
</a>
124 <a href=
"thread.html#2089">[ thread ]
</a>
125 <a href=
"subject.html#2089">[ subject ]
</a>
126 <a href=
"author.html#2089">[ author ]
</a>
projects / irc.git / blob