[Kolab-devel] IM and document store applications

Tue May 11 08:08:08 CEST 2010

Hi,

Quoting "Mailingliste TBits.net GmbH" <mailinglists at tbits.net>:

> (I'll just go crazy and cross-post this, hope no-one minds...)
>
> The higher-ups commanded that I implement two more Horde applications.

Ah, looks like I should get used to your style of writing :)

> Maybe something to that effect already exists somewhere in the depth
> of the repository?
>
> One is a 'messaging module', i.e. something akin to e-mail, only with
> some of the properties of SMS and the likes. The basic ideas seem to
> be that
>      * a window pops up when a new message is received
>      * the user may 'reply' after reading it
>      * the 'conversation' is kept in the archive and can be reviewed later
> This shall be reserved for 'internal' communication, i.e. a message
> should never leave the company network.
> Perhaps the messages could be internally mapped to actual e-mail,
> 'delivered' by injecting them into an appropriate (world writable?)
> IMAP folder in the recipient's inbox. The thread of conversation could
> be tracked via 'In-Reply-To' header. Now to just find a way to
> periodically check for new IMs, regardless of which application is
> currently being used...

Hm, I'm not yet certain you'd really want to store that in IMAP  
though. I certainly like this Kolab concept a lot more than you do :P  
but in that specific case you might easily get performance problems.  
Assume you have a team of about a hundred co-workers that are  
constantly polling IMAP for new messages. And in case some of them are  
active chatters you quickly fill your IMAP folder with plenty of  
messages.

An alternative might be to store the data in memcached first and  
archive it into IMAP for later review. This is just a rough idea  
though and depends a lot on the different use cases for the application.

I don't think Horde has such an application already.

>
> The other is a 'document management module', where users can
> (basically) upload files everyone else can then download when needed.
> This sounds suspiciously like Gollem could be used as a base, only
> with some sort of tagging mechanism added to it in order to link files
> to projects, customers and whatnot.

Yes, I agree.

> However, the version of Gollem
> from git cannot seem to work with the Horde/PHP/whatever distribution
> provided by Kolab (at least I didn't manage to get it running and the
> code looks like it wants H4). I suspect some hacking needs to be done
> for it to fit the environment?

This won't be possible without an unreasonable amount of hacking. The  
purpose of the version number Horde 3 and Horde 4 is to allow the  
Horde developers to completely break backward compatibility between  
the application stack and the framework (the libraries required by  
each application). I hope we will be able to loosen this tight  
coupling with Horde 4 but I'm not too optimistic at the moment.

Horde 4 has a tagging system. I don't know if that is already  
available within Gollem though. It wouldn't be hard to add it though.

However we don't support Horde 4 on the Kolab server at the moment. In  
fact it is not even released yet. So your choice would depend on the  
time you want to have the application ready. Probably tomorrow :) -  
then you should go for Horde 3.

> Since Gollem isn't in the Kolab distro,
> there must be something like that. At any rate, the bosses (and
> probably the whole Kolab crowd as well) will want the files stored in
> IMAP (insert snide remark here), so an appropriate backend would need
> to be implemented whether Gollem can be used or not.

This exists at least as a hack. I wanted that functionality myself and  
coded such a driver a year ago or so. It does still have some issues  
though. And it would of course be nice to discuss the storage format  
on kolab-format.

>
> Once again, the image in the Boss Man(tm)'s head is very likely that
> he will get something that is essentially a clone of what we are using
> now (i.e. of the system sold by the guys at www.infra-struktur.de). On
> the other hand, of course, I must insist that abstraction not be lost
> and the results of development work independently of both the notions
> established within our company the whole Kolab dealie (I figure this
> should sit well with the Horde crowd).
>
> Bottom line:
>      * If such applications already exist without us knowing, perhaps
> they could be adjusted to meet the big-wig's expectations.
>      * If there are concepts or ways of doing things that would lend
> themselves well for this, feel free to point them out.
>      * If such applications are actually wanted, they could be merged
> (or somesuch) when we come up with some code. If they are not,
> nevermind.

It looks like you are forced to work a while longer with things such  
as Kolab_Storage. I like that thought :) Can you do you me a favor and  
pipe as many questions and critical comments as possible concerning  
the Kolab_* libraries to this channel? I really mean that as it might  
help me to improve the code as well as the documentation. And if you  
are lucky it also helps to to understand some of the more obscure  
regions of the code.

Cheers,

Gunnar

>
> Sincerely,
> Simon Bausch,
> currently with TBits.net GmbH
>
>
> ----------------------------------------------------------------
> Diese Nachricht wurde versandt mit Webmail von www.tbits.net.
> This message was sent using webmail of www.tbits.net.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100511/9079cc5b/attachment.sig>