Hey everyone, Hopefully people will have noticed my blog post on the recent changes to the store in my experimental branch - it's looking reasonably good and hopefully mergable soon. It's my intention to do some kind of roll-up release for the server side bits of Bongo next week sometime as the prelude to 0.4.
There are some changes to the store protocol I've already made, and some I want to make or am thinking of making. The rationale for each is different, and I'll go through them all - if anyone has any thoughts on any or all of these, please let me know. First, some easy ones: MFLAG - alter flags on many documents at one MWRITE - write to many documents at once The problem with these two is that they can't do things atomically - you can't alter a whole load of docs without locking the collection. They turn out to be equivalent to doing FLAG or WRITE a number of times, and the conversation isn't really any shorter save a couple of bytes a line. I already removed this from the experimental store. I couldn't find any code actually using them; the Python lib doesn't even bind them. CONVERSATION - seems like the weaker sibling of CONVERSATIONS. Not sure why it exists. CALENDARS - probably put in place before calendars had their own documents. I think we can get rid of this; I doubt anything uses it and it's just a LIST for all intents and purposes. LINK / UNLINK - these are currently calendar-specific commands. I want to change this so that you can link/unlink any two documents. This isn't a huge change really. TIMEOUT - this is used to control retry access to the store SQLite database. It should be obsolete now, since we control access at a higher level. I also propose to do away with the unimplemented commands CAPABILITY, CONFIGURATION, HELP, NVER, QUOTA, USERS, and VERIFY. Harder ones: MESSAGES - basically, pull back mail documents which meet certain criteria. This is really Dragonfly-specific. Potentially, this kind of thing should be done via a more general search function I think - although MESSAGES is already horrifically complicated parameter-wise. I'm not sure it's worth doing anything about this right now, but the experimental store doesn't support it yet... :) PROPGET - well, not the command itself, but a couple of properties at least. You can get back the contents of a document by doing 'PROPGET <id> Pnmap.document', which is equivalent to 'READ <id>'. You can't PROPSET it, and it doesn't make much sense as a property either, so it really ought to die. In similar terms, the ACLs shouldn't be properties in my opinion, because that requires client and server to parse the ACL syntax. At the moment, you can set ACLs by doing 'PROPSET <id> Pnmap.access-control', but that's not a great model. I'd rather have something like: ACL GRANT <id> ALL READ ACL LIST <id> ACL REMOVE <id> <whatever.. > ... that way neither server nor client need to parse ACLs, and maybe we also have some policy on being able to set/remove ACLs other people put in place in the future sometime. There is also an "alarm" property which you can set to bring out data when you call ALARMS. That needs some real investigation. Stuff for the future perhaps: MAILINGLISTS Again, a Dragonfly-ism. I'm sure we do use it, and there's no obvious replacement for it, but it feels very specific. I'm not totally sure why you'd want to know what unique mailing lists were in any particular collection without actually looking at a set of mails which were part of mailing lists.. WRITE vs REPLACE I'm not totally sold on this being two different commands. Any thoughts? Alex. _______________________________________________ Bongo-devel mailing list [email protected] https://mail.gna.org/listinfo/bongo-devel
