On Sun, 2004-06-27 at 22:39 +0100, Dave Cridland wrote: > On Sat Jun 26 05:42:43 2004, seth vidal wrote: > > On Sat, 2004-06-26 at 00:40 -0400, Havoc Pennington wrote: > > > The way to fix it of course is to have a central config server > > (maybe > > > just a file server or webdav server, maybe an LDAP server though > > LDAP > > > sucks for writes) rather than having arbitrary machines talk to > > each > > > other. > > > > Has any consideration been given to using a modified imap server > > for the > > storage? you could keep the data format more or less the same, the > > tricks would be auth and locking, but both of those have been > > handled in > > imap before. > > > > > Oh, dear, please, no. > > IMAP is designed to handle email messages, which have the useful > feature that they don't change after delivery - just a very small > amount of metadata about them does. (In IMAP's case, flags). IMAP > takes huge advantage of this, so much so that nobody serious has used > IMAP for storage of anything but email messages. (Yes, yes, I know > there's a crowd of people who try to slam vCard data in each year, > whose projects vanish into oblivion.) > > LDAP, fine - it's designed as 'the one true data', but it can be > coerced, just about, into handling per-person data, even if getting > updates is a pain. If you dig way way back into the GConf archives, probably a few years, you should find a patch that provides an LDAP backend. It is written for GConf 1.x but shouldn't be too hard to port across. I don't think I had notifications working in it, it was a first patch for read/writing values into LDAP which didn't seem to get interest at the time. It has been since mentioned that it would be an acceptable patch for GConf but my interest in updating it has since been usurped by other projects. I've not really looked into ACAP so can't comment on that part. Though it gets a mention whenever LDAP does as the better way todo this, the counter argument always is that openLDAP is much more stable than the ACAP server. IMHO having the option to use either would be the nicest, then it depends on me as to which server I like more for my GConfing. > > WebDAV, fine - after all, everything should run on port 80 to be > taken seriously these days. Quite why we're using this dull old port > 25 for this discussion is beyond me - imagine using an old protocol > designed for the task in hand. But yes, sarcasm aside, WebDAV can be > coerced into handling configuration data. > >
Attachment:
signature.asc
Description: This is a digitally signed message part