Re: Wiki, information on database back ends.

2010-09-15 Thread Jeroen van Meeuwen (Kolab Systems)
Dan White wrote:
 The current imapd.conf hints at the available data types for each cyrus
 database. Depending on the option, the following database types are
 available (in 2.3.16):
 
 (...snip...)
 
 I don't know why the (rpm) upgrade script chose skiplist as an
 intermediate format, rather than flat. Perhaps skiplist hasn't changed much
 between major versions, and offers a speed benefit.
 

Actually the RPM packages patch up lib/imapoptions to default to skiplist for 
all databases. The script choosing skiplist as the default format to convert 
databases to is nothing but a choice that makes a default export/import much 
faster because the script does not actually have to export/import (it merely 
has to detect/determine/compare/continue).


 As far as skiplist, that seems to be a proprietary format.

 skiplist: ?
 

http://git.cyrusimap.org/cyrus-imapd/tree/lib/cyrusdb_skiplist.c is the 
implementation of http://en.wikipedia.org/wiki/Skip_list inspired by 
ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf.

I fail to see how exactly this could lead to the conclusion it may be 
proprietary software.

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeu...@kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08


Re: Wiki, information on database back ends.

2010-09-15 Thread Dan White

On 15/09/10 21:19 +0200, Jeroen van Meeuwen (Kolab Systems) wrote:

As far as skiplist, that seems to be a proprietary format.

skiplist: ?



http://git.cyrusimap.org/cyrus-imapd/tree/lib/cyrusdb_skiplist.c is the
implementation of http://en.wikipedia.org/wiki/Skip_list inspired by
ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf.

I fail to see how exactly this could lead to the conclusion it may be
proprietary software.


Not proprietary software, but a proprietary database format, in that it's
specific to Cyrus, as opposed to something like Berekely, where there's
external documentation.

I'm not trying to make a judgement, just trying to answer the question
what is skiplist?, which due to my own ignorance I can't answer.

--
Dan White


Re: Wiki, information on database back ends.

2010-09-14 Thread Jeroen van Meeuwen (Kolab Systems)
Patrick Goetz wrote:
 On 09/14/2010 02:24 PM, Patrick Goetz wrote:
  This raises a number of questions, though:
 I forgot to add:
 
 4.
 The Redhat script uses a file called
 /usr/share/cyrus-imapd/rpm/db.cfg
 
 Presumably this is specific to the redhat package, since I can't find a
 db.cfg file associated with my 2.1.16 cyrus server, or is my version
 just too old and behind the times?

This file is also written out by the same script. The location of the script 
(the mentioning of 'rpm/' in the path) is completely arbitrary (for all the 
script cares the file lives in /boot/).

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeu...@kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08


Re: Wiki, information on database back ends.

2010-09-14 Thread Patrick Goetz

On 09/14/2010 04:06 PM, Jeroen van Meeuwen (Kolab Systems) wrote:


This file is also written out by the same script. The location of the script
(the mentioning of 'rpm/' in the path) is completely arbitrary (for all the
script cares the file lives in /boot/).



Small correction:  created while compiling; from the comments in the 
script and the actual lines of code the file appears in:


# The format of current db files is determined using the 'file' command
# with a magic file added for skiplist db, the new format is read from
# a config file usually in /usr/share/cyrus-imapd/rpm/db.cfg, which is
# created while compiling. After converting, the db.cfg file is
...
db_cfg=${data_dir}/db.cfg
db_current=${imap_prefix}/rpm/db.cfg.current
db_cache=${imap_prefix}/rpm/db.cfg.cache

# source default db backend config
. $db_cfg



Re: Wiki, information on database back ends.

2010-09-14 Thread Dave McMurtrie

Patrick Goetz wrote:

On 09/14/2010 02:35 PM, Dave McMurtrie wrote:

On 09/14/2010 03:24 PM, Patrick Goetz wrote:

The flip side of this is that you are now welcome and encouraged to
change that.



I'd be happy to write up some stuff as soon as I have answers to some of 
my questions (i.e. as soon as I have something to write about).




I added some basic information to the FAQ in the Questions about 
features section to attempt to answer your database backends question. 
 It doesn't fully answer your question, but it's a start.



I've spent quite a bit of time looking at cyrus 2.3.16 source code this 
summer, and it sure would have been helpful if the coders had taken 30 
seconds or a minute to write a few comments for each function.  Just 
sayin


There aren't a ton of style guidelines for the Cyrus codebase other than 
http://www.cyrusimap.org/mediawiki/index.php/Cyrus_IMAP_Hacking


Specifically, I'm not aware of anything that tells a developer to add a 
comment for each function.


Since we're aiming to attract more developers to the project, I'm 
planning to soon open this topic up for further discussion with the core 
developers.


Now that you've studied the code, if we can get core developer agreement 
on having a standard comment blurb for each function, would you be 
interested in submitting patches to include these comments?


Thanks,

Dave


Re: Wiki, information on database back ends.

2010-09-14 Thread Bron Gondwana
On Tue, Sep 14, 2010 at 03:04:33PM -0500, Patrick Goetz wrote:
 On 09/14/2010 02:35 PM, Dave McMurtrie wrote:
 On 09/14/2010 03:24 PM, Patrick Goetz wrote:
 
 The flip side of this is that you are now welcome and encouraged to
 change that.
 
 
 I'd be happy to write up some stuff as soon as I have answers to
 some of my questions (i.e. as soon as I have something to write
 about).
 
 I've spent quite a bit of time looking at cyrus 2.3.16 source code
 this summer, and it sure would have been helpful if the coders had
 taken 30 seconds or a minute to write a few comments for each
 function.  Just sayin

Tell me about it.  Though I have to warn you, a LOT has changed in
what will become 2.4.  I'm trying to document it better

Bron.