[Kroupware] Re: Sharing of Calanders

[Lutz Badenheuer]

Hi Marc, 

Am Dienstag, 7. Januar 2003 00:03 schrieb Marc Mutz:
> On Monday 06 January 2003 21:09, ralph escherich wrote:
> 
> > If you guys want to, then I could compile a little feature list
> > and you can decide what you want to support or not.
>
> It's not the question whether or not we _want_ to support
> additional features. Of course we we'd like to. But we're paid by
> the BSI to implement a fixed set of features (those in their
> requirements catalog) and we can't afford to do much more than
> that, given that we should have this ready better yesterday than
> tomorrow ;-)

ok, I do understand this. But OTOH, in my opinion we should think of 
what will come after that project. 

Well, I'd like to think about the possibility to add Perl-Qt support 
to the server to simplify administration -- and later to the clients 
to simplify mapping workflow processes and collaborative works onto 
kolab. Maybe an X server and a modified version of pam_scp could do 
some simple tricks for the clients... 

Perl-Qt will be a perfect base for this kind of work. I've found to 
make Perl bytecode getting interpreted by Linux' OS kernel (actually, 
by the kernel calling perl -e using binfmt_misc) and am searching for 
ways to secure SUID perl bytecode executables. To me, Perl-Qt with 
Qt-Designer looks easier than VB... 

What about a simple trouble ticket or CRM system? Adding some -- I 
don't know the english word for "Finanzbuchhaltung" -- will perfectly 
serve corporate environments, too. Centralize data wherever you can. 
What about including Samba (maybe as PDC) for file and printer 
sharing? Everything is open. Centralize... you get the idea. 

> But of course this is a Free Software project, so when the
> Kroupware project has finished, 

Please do not pick up my suggestion as criticisms, but I think we 
should -- well, at least collect ideas what to do with kolab when 
BSI's project is done. At this time, I see the end of the BSI 
contract and a huge black hole afterwards. What are we going to do 
with a very flexible and scalable, and either platform-independent 
kolab server? I think most people here want to build solutions with 
this software and so do have their own thoughts how to enhance this 
bunch of programs; maybe it'll be a good idea not only to collect 
these vagaries but also keep further-going ideas into the scope of 
the active developers. 

In my opinion, this project will only succeed when being MUCH better 
than the existing solutions. This includes documentation, features, 
stability, security, flexibility and ease-of-use as well -- which is 
a dance on the ridge, I admit. So please keep in mind what this work 
is going to evolve when the contract will be done. 

Best wishes, 
Lutz 

-- 
Lutz Badenheuer     | IT--Consulting, Development, Networksolutions
luke@the-web-ac.com | C/C++, OO-Perl, sh | Linux, SCO UNIX, Solaris