eGroupware resources in KDE3.2

[Cornelius Schumacher]

On Saturday 06 December 2003 21:42, Tobias Koenig wrote:
> On Sat, Dec 06, 2003 at 09:29:09PM +0100, Cornelius Schumacher wrote:
> > On Saturday 06 December 2003 00:57, Tobias Koenig wrote:
>
> > > The code compiles and works fine in my test case with the
> > > egroupware server at egroupware.org. Since the code is compiled
> > > as resources there won't be any additional bugs (as long as you
> > > do not use the plugins ;)) so it won't hurt the freeze much IMHO.
> >
> > Does it add new strings?
>
> Yes, the configuration dialogs.

Couldn't you reuse some existing strings? Besides the string 
"eGroupware" which probably doesn't need translation I don't see any 
need for specific strings.

> > > I think having at least one groupware solution in the official
> > > KDE 3.2 release would also be good for PR (since the Kolab
> > > integration will come foremost in a later 3.2.X release).
> >
> > Have you tried it with a real eGroupware setup? The test server at
> > egroupware.org and the setup at LinuxWorldExpo in Frankfurt weren't
> > very realistic environments. I wonder, if the resources still work
> > satisfactory if you have thousands of contacts and appointments.
>
> I guess with thousands of contacts it won't perform very good because
> of the concept of the resource framework (libkcal and libkabc...) to
> load all data at once... for small companies it should do the job.

It's not a concept of the resource framework to load all data at once. 
It's a limitation of libkabc. In libkcal this isn't necessary. A 
calendar resource should be able to only load the data that actually is 
required.

I think we really need to test this before adding it to the release. 
Increasing the startup time of Kontact by some minutes by adding a 
eGroupware resource would make a really bad impression.

> > If the resources work under real-world conditions in a way which is
> > useful I'm in favor of adding them to HEAD now. But just adding
> > them for the sake of having support for a groupware server wouldn't
> > be the right thing.
>
> It's not just that, but more people cloud have a look at them and
> help on fixing bugs ;)

The eGroupware resources don't necessariliy have to be part of the KDE 
3.2 release. They could also be released separately when 3.2 is out. 
This would require libkcal to be a public API, though. Maybe we should 
take the step of making it public with 3.2. This would require some 
changes (adding d-pointers and similar stuff). I'm also not really sure 
that the API is ready for this. Maybe a compromise of making it public 
but with notice to change in 3.3 or whatever comes after 3.2 would be 
appropriate.

-- 
Cornelius Schumacher <schumacher at kde.org>