[IRCServices Coding] get_nickinfo like functions suggestion

[Andrew Church]

     Easy counterexample: /os akill add luser@*.example.com (where it
would definitely _not_ be proper to use out-of-date data)

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>
>After discussing mysql module design it occurred to me that it would make 
>designing a
>caching database module for mysql much easier if the get_ functions had 
>analogs for
>read-only use.
>
>I figure that if we create functions like get_readonly_nickinfo, it would 
>allow
>for more efficient caching of data. The reasoning behind this is that 
>procedures
>which modify a nick/channel/nickgroup need to have a more updated version 
>of the
>data in order to figure out whether it can be modified the way it wants to.
>
>On the other hand, many functions that only read from these pieces of data
>would not have to have the most recent version and could use the cached 
>version
>since it would cause little harm to simply display out-of-date information
>to the user.
>
>If we cached all pieces of data (including read-write), then it would 
>happen
>that either the data in the database would be locked for too long and no 
>outside
>program could ever modify it, or if we didn't lock the entries in the 
>database,
>we would end up overwriting any changes another program made once we 
>invalidated
>the cache.
>
>So basically I propose creating database functions using names like 
>get_readonly_nickinfo
>or get_readonly_chaninfo, which would be used by commands such as INFO, 
>ACCESS LIST,
>AKICK LIST, AKILL LIST, and for determining access etc. The regular 
>get_nickinfo etc
>functions would retain the same functionality for backwards compatibility 
>and nothing
>would break.
>
>These new get_readonly_* (or if you want, get_cache_*) would be implemented 
>in modules
>that cache nick information in memory. In modules where either a) 
>information is ALWAYS
>read from database on get_* or b) all information is always in memory, they 
>would be
>synonyms for the regular get_* functions (i.e. in version4, they would be 
>synonyms).
>
>The info returned by these functions would generally not be modified (save 
>for things
>that aren't saved to database such as the locked field) and wouldn't be 
>passed to
>put_* functions. Also, it would be a bad idea to use the info returned from 
>the
>readonly/cache functions to conditionally modify other data (example, you 
>wouldn't
>use these functions to check someone's access so that they could change 
>channel options,
>since another program could recently have removed them from the access list 
>without
>us knowing it. It would be safe however to check someone's access to join 
>the channel,
>use INVITE UNBAN OP etc, because that doesn't involve changing the 
>ChannelInfo).
>
>If I seem to be spouting gibberish, by all means ask me to clarify.
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding