[Kolab-devel] "questions and critical comments"

[Mailingliste TBits.net GmbH]

[quote=Gunnar Wrobel]
     Can you do you me a favor and pipe as many questions and critical comments
     as possible concerning the Kolab_* libraries to this channel?
[/quote]

Perhaps the greatest criticism I have is also the most obvious;  
however I'm aware you will not heed this advice unless you actually  
*do* throw *everything* away and start over from scratch (which you  
should): The whole IMAP storage thing. Seriously? Storing  
contacts/tasks/etc. as XMLs attached to mail? Please! Just imagine  
having a module that requires lookups by anything other than UID  
and/or joins (in SQL parlance). (And at least now, you do; anything  
more complicated than Mnemo will eventually do this...) This will  
quickly give you O(n^2) runtime complexity or worse.

I say, when (and note my use of 'when' rather than 'if') you redo  
everything from scratch, I advise you ditch the level of indirection  
that is OpenLDAP and dump everything (including the 'groupware  
objects') right into an embedded database (BerkeleyDB or somesuch,  
SQLite if you feel nostalgic) and replicate it right back to the  
clients, which can then work with their local copy of the database for  
offline availability. No servers needed, nothing.

Next, I feel compelled to mention that the parts I've seen are quite  
broadly distributed across like two dozen files and classes -- not a  
bad thing per se (if done right, quite on the contrary), but since  
*none* of it is properly documented (or at all) someone looking for a  
problem will be lost in the depths forever. If you want people  
developing stuff for it, you should *seriously* consider giving out  
API docs for your stuff. Also, do some runtime checks so bad data  
(notably malformed XML) doesn't cause PHP to die and/or spit out  
incomprehensible messages; I've run into this more than once during  
development and ended up wiping the IMAP account because testing had  
driven the storage logic into a corner.

It also seems that the caching dealie is somewhat buggy, on more than  
one occasion I created an object, then had to log out and back in  
before it actually showed up in the list -- other times it worked  
without doing anything. Curious.

Of course, you already know that requiring people to modify both the  
Horde *and* Kolab code when adding new modules (or rather, storage  
formats) is not the best of ideas. One better way would be doing what  
Horde itsself does quite frequently: Dumping definitions into separate  
files and include()ing *.php there.

As for questions, what I always wondered: How can you assign a storage  
format (i.e. one from $HORDE/lib/Horde/Kolab/Format/XML) to a folder  
(i.e. "share")? My modules often have more than one such format and I  
routinely used the union of all of them as "the" format; surely there  
is a better way?

Also, I've seen that even the latest (release) version of Kolab uses a  
Kolab::_storage of Kolab_Storage_Deprecated -- does that mean there is  
some brand-new system being developed that will kick in shortly? Just  
curious... Funnily enough, the other modules (and, since "copying"  
code from them is the only form of docs available, mine as well) seem  
to happily access aforementioned field in their storage driver, even  
though the underscore suggests that this should not be done. Is there  
any more canonical way?

Those are the ones I can think of for now.

Sincerely,
Simon Bausch


----------------------------------------------------------------
Diese Nachricht wurde versandt mit Webmail von www.tbits.net.
This message was sent using webmail of www.tbits.net.