January 1999
- From DevMud: Database module Greg Connor
- From DevMud: Database module Mik Clarke
- From DevMud: Database module Greg Connor
- From DevMud: Database module J C Lawrence
- From DevMud: Database module Greg Connor
- ADMIN: Resends and possible duplicates J C Lawrence
- Info about different skill systems Emil Eifrem
- Info about different skill systems Nathan F Yospe
- Info about different skill systems Ben Greear
- Info about different skill systems Emil Eifrem
- Info about different skill systems Ben Greear
- Info about different skill systems Emil Eifrem
- Info about different skill systems Nathan F Yospe
- Info about different skill systems Travis S. Casey
- Info about different skill systems Mik Clarke
- New features for ScryMUD (Player-run Shops) Ben Greear
- [OT Humor] Mudder's Rhapsody Jon A. Lambert
- [OT Humor] Mudder's Rhapsody Caliban Tiresias Darklock
- [OT Humor] Mudder's Rhapsody The Wildman
- Guild/skill/spell relation (or "webs") Petri Virkkula
- Guild/skill/spell relation (or "webs") David Bennett
- mobile movement Matthew Mihaly
- mobile movement Adam Wiggins
- mobile movement Koster, Raph
- mobile movement Caliban Tiresias Darklock
- mobile movement David Bennett
- mobile movement Kylotan
- mobile movement quzah [softhome]
- mobile movement Ling
- mobile movement J C Lawrence
- mobile movement Oliver Jowett
- mobile movement Oliver Jowett
- mobile movement Caliban Tiresias Darklock
- mobile movement Richard Woolcock
- mobile movement J C Lawrence
- mobile movement Ling
- mobile movement Marc Hernandez
- mobile movement J C Lawrence
- mobile movement Ling
- mobile movement Holly Sommer
- mobile movement Caliban Tiresias Darklock
- mobile movement Koster, Raph
- mobile movement Chris Gray
- Intelligent WebGlimpse archive searching at Kanga.Nu (was J C Lawrence
- [RRE]MediaMOO annual birthday symposia: 1/20 Bruce Mitchener, Jr.
- [RRE]MediaMOO annual birthday symposia: 1/20 Koster, Raph
- OT: Mike Sellers needs some help load testing J C Lawrence
- Keegan's MUD Tree J C Lawrence
- Intelligent WebGlimpse archive searching at Kanga.Nu Marian Griffith
- Intelligent WebGlimpse archive searching at Kanga.Nu Caliban Tiresias Darklock
- Intelligent WebGlimpse archive searching at Kanga.Nu Dominic J. Eidson
- Intelligent WebGlimpse archive searching at Kanga.Nu J C Lawrence
- Intelligent WebGlimpse archive searching at Kanga.Nu Marian Griffith
- GRASS GIS Web Site Elis Pomales
- Thoughts Caliban Tiresias Darklock
- mobile movement (the fault of tracking) quzah [softhome]
- ADMIN Name server problems and upes J C Lawrence
- Adjective Server Christopher Allen
- Reputations, More Mazes Eli Stevens {KiZurich}
- Reputations, More Mazes J C Lawrence
- Reputations, More Mazes Eli Stevens {KiZurich}
- Mules (was something different) Marian Griffith
- Mules (was something different) J C Lawrence
- Mules (was something different) Hans-Henrik Staerfeldt
- Levels versus Skills Marian Griffith
- Levels versus Skills Caliban Tiresias Darklock
- Levels versus Skills J C Lawrence
- Levels versus Skills quzah [softhome]
- Levels versus Skills Vladimir Prelovac
- Levels versus Skills quzah [softhome]
- Levels versus Skills J C Lawrence
- Levels versus Skills Petri Virkkula
- Levels versus Skills J C Lawrence
- Levels versus Skills Caliban Tiresias Darklock
- From Devmud: Database module, draft 3 Greg Connor
- Matrix Game Ling
- Graphic design doc Thinus Barnard
- Graphic design doc Chris Gray
- ADMIN: List server and Kanga.Nu host changes J C Lawrence
- ADMIN: List server and Kanga.Nu host changes Koster, Raph
- Sockets and fibers Caliban Tiresias Darklock
- Sockets and fibers Adam J. Thornton
- Sockets and fibers Caliban Tiresias Darklock
- Sockets and fibers J C Lawrence
- Sockets and fibers Jon A. Lambert
- Sockets and fibers Adam J. Thornton
- Sockets and fibers Dr. Cat
- Sockets and fibers Jo Dillon
- [DevMUD] From Devmud: Database module, draft 3 Greg Connor
> > = [Greg Connor:]
> >This was because db_direct_writeable_record gives you a writeable record,
> >but doesn't actually "write" to the database until you release it, so
> >"write" might be misleading. The closest action word is probably "get" ..
> >I think I had that in there and took it out to shorten it a bit :)
>
> = Chris Gray wrote:
>Hmm. OK. The consistency and clarity of the naming does suffer a bit,
>however. Even though I dislike long names, I'm tempted to suggest
>putting the 'get' and 'put' back.
You're probably right... why save a few characters at the expense of
clarity? :)
> >[when getting fields one at a time...]
> >A lock would be useful to the client, but I'm still going to try to weasel
> >out of implementing one. What if you could mark several fields that you
> >want to fetch (like setting a flag in the db_record header) and sumbit one
> >call to get them all? This might save some overhead too, for network
> >sources.
>
>That would work. Some solution is needed here, and I understand your
>reluctance to require locking. Locks bring up the whole question of
>how you make someone wait on a lock - sounds like you need a spec
>for a core-provided threading package, at least a wait-for-lock entry
>(which should always just return in a non-threaded server).
You're right, I hadn't thought about the locks that much. Locks and
threading would probably add up to trouble. I'll enable multiple things to
be fetched at once and keep "lock" out of the interface for now.
In the direct mode, where I have a lock/release defined, it's not designed
for threading, just to keep you from doing something silly, so returning
with an error would be appropriate. If your server is single-threaded, not
much sense calling wait()...
I am probably going to move the direct mode calls to the "not now,
investigate for version 2" list. I dread the thought of implementing locks
if they're only going to be used as an optimization (and a dubious one) and
limited to single-threads. I will probably have a better feeling for
whether this is needed when the prototype method-2 only version can be tested.
> >Db_record (the structure) is what you said second: address/length pairs
> >(possibly some flags to go with each field, like whether it is loaded,
> >null, requesting to be read, requesting to be written, etc).. It is only
> >variable in size to the extent that you will add or remove fields.
>
>Ah, ok. So, db_get_record_header_size says how big the db_record
>structure for that record will be and db_get_record_header copies the
>struct in. Given that, why does one need db_get_field_size? If the
>user is to be able to examine/set flags per field, then the contents
>of a db_record are public. It could be implemented as a macro, but a
>call to it will be longer than just grabbing the length directly.
You're right.. I had "get_field_size" in there for symmetry but it isn't
really needed. db_record should be a public structure type... it might
have some fields that only make sense to dbmodule itself (like revision
info or some other cookie to validate write-back changes) but I think that
won't bother things much. So strike the "get_field_size".
Size info might be out of date if someone else modified the record between
one fetch and the next, but in this case you would get a "not big enough"
error and realloc/try again. There should be a call to refresh the header
(maybe just calling get with no fields marked would do this).
Thanks for the feedback. I'll revise the spec again this week or this
weekend with the changes to date. I may even get to write some code this
weekend (er, if header files count :) - META: list "peerage" Koster, Raph
- META: list "peerage" John Bertoglio
- META: list "peerage" diablo@best.com
- META: list "peerage" Andy Cink
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Quzah [softhome]
- META: list "peerage" Michael.Willey@abnamro.com
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Holly Sommer
- META: list "peerage" Travis S. Casey
- META: list "peerage" Andy Cink
- META: list "peerage" Quzah [softhome]
- META: list "peerage" Matthew D. Fuller
- META: list "peerage" Laurel Fan
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" David Bennett
- META: list "peerage" Bruce Mitchener, Jr.
- META: list "peerage" diablo@best.com
- META: list "peerage" Matthew D. Fuller
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Brandon A Downey
- META: list "peerage" Travis Casey
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Dominic J. Eidson
- META: List "peerage" Marian Griffith
- META: List "peerage" Caliban Tiresias Darklock
- META: list "peerage" Ola Fosheim Grøstad
- META: list "peerage" Sayeed
- Mugu Chris Gray
- META: List peerage and behaviour J C Lawrence
- META: list "peerage" Chris Gray
- ADMIN: We're working again. J C Lawrence
- Java I/O and threads. Elis Pomales
- Java I/O and threads. Jo Dillon
- Java I/O and threads. cynbe@muq.org
- Java I/O and threads. Jo Dillon
- Java I/O and threads. Elis Pomales
- Reset Death Wes Connell
- Reset Death Quzah [softhome]
- Reset Death Wes Connell
- Reset Death Mik Clarke
- Reset Death Andrew C.M. McClintock
- Reset Death Mik Clarke
- PvP and mob capacities (was "List Peerage") Caliban Tiresias Darklock
- combat diablo@best.com
- META: list "peerage" Darrin Hyrup
- META: list "peerage" J C Lawrence
- Telmaron and Mud servers was: META: list "peerage" Elis Pomales
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Ben Greear
- Who is? (was about level vs skills) Marian Griffith
- Who is? (was about level vs skills) Caliban Tiresias Darklock
- exploration points diablo@best.com
- [MUD-Dev] Juha Lindfors
- Stock Mud Demographics ##Make Nylander
- ADMIN: Off-topic and the ever present reminders on quoting. J C Lawrence
- Mud reviewing Andy Cink
- Mud reviewing Caliban Tiresias Darklock
- Mud reviewing diablo@best.com
- Mud reviewing Andru Luvisi
- Mud reviewing diablo@best.com
- Mud reviewing J C Lawrence
- Mud reviewing Dan Shiovitz
- Mud reviewing diablo@best.com
- Mud reviewing Caliban Tiresias Darklock
- Mud reviewing diablo@best.com
- Mud reviewing Richard Woolcock
- Mud reviewing David Bennett
- Mud reviewing Caliban Tiresias Darklock
- MUD Admin skills Hal Black
- Subdue Holly Sommer
- processors diablo@best.com
- processors John Bertoglio
- processors Wes Connell
- processors Laurel Fan
- processors Mik Clarke
- processors J C Lawrence
- processors diablo@best.com
- processors Quzah [softhome]
- processors Mik Clarke
- processors J C Lawrence
- processors Marc Hernandez
- processors Adam Wiggins
- processors Greg Underwood
- processors Adam Wiggins
- processors Chris Gray
- processors gunderwood@donet.com
- processors Jon A. Lambert
- processors Greg Underwood
- processors Petri Virkkula
- quests involving players diablo@best.com
- quests involving players Darren Henderson
- quests involving players Caliban Tiresias Darklock
- quests involving players Richard Woolcock