[Kolab-devel] Brain Dump of the Week: Ideas, Plans and Realities ...

[Sascha Wilde]

Richard Bos <ml at radoeka.nl> writes:
> Op dinsdag 17 november 2009 16:36:21 schreef Sascha Wilde:

>> 2. Packaging and Distribution Future
[...]
> May I point your attention to the openSUSE build service?  Contrary its name, 
> the build service is for all mainstream distributions, like the rpm based 
> Fedora, Mandrake, Centos and of course openSUSE. 

Thanks for your input.  I don't know the openSUSE build service, so I'm
currently not really qualified to judge it -- from what you wrote I have
to admit that it sound interesting but at the same time I'm not sure if
it really addresses our primary problems.

I'll have a look at it (just a matter of having reasonable time, as always).

[...]
>> One thing we agreed upon is, that it would be nice to have all the
>> sources in a none discriminating package format (can you say "tar"?)
>> available, distributed and build able, so that one could easily build
>> Kolab server without having the pre-requisite of OpenPKG -- Gunnar
>> recently started a thread on this topic.
>
> See above.  The build service does not have an openpkg repository.  That would 
> have been nice.   I think that it is a bit hard to set up, besides that it is 
> not very known.

I'm not sure how your comment relates to the paragraph above, I was
talking on classical tar packaging, not OpenPKG -- or are you saying we
would need the tars to use the build service?

[...]
>> - Keep horde as basis for the web client, which would include the switch
>>   to horde 4.  As there is very little hope that the horde project will
>>   come up with a polished and shiny modern UI anytime soon, this would
>>   mean that we will have to invest a serious amount of time and work our
>>   self to contribute what would basically be a complete new horde UI.
>
> What do you mean with a polished and shiny UI?

I mean a UI that can compete with other groupware web clients, in terms
of the user experience.  That means: interactivity, speed and a modern
look and feel.  Good web applications these days do nearly match native
clients in these respects.  Users (and customers for that matter) know
this, they have seen and often used web applications like those of
google, zarafa or open-exchange for example and they expect us to
provide something comparable.

> Do you mean that the Horde-4 won't provide e.g. the Silver theme (the
> one that kolab-webclient uses now)?

No, I mean that Horde-4 will not be up to pair with modern web
interfaces with regard to the UI.

It is said that there will be a new dynamic calendar component, but I
haven't seen it my self yet.  I hope this will be an major improvement
(the current calendar component is very cumbersome to use), but even
then I doubt that the over all user experience will be competitive.

> What is the current state of Horde-4?  Will it be available in 2010 (what 
> quarter).

I don't know -- to my understanding "its ready when its ready".  And
realistically we will not be able to switch the client to Horde4 before 2011...

> Will it be easier to package (rpm / deb), than it used to be?
> If Horde-4 meets its promises, it should be easy to connect / integrate 
> Horde-4 with kolab server.  If that is the case the kolab project gets a nice 
> web interface almost for free.  Its perhaps not as shiny as the Zarafa or the 
> Google mail GUI, but it is still a nice GUI.

I don't know what promises are really made by Horde-4, maybe Gunnar can
give some detailed answers here.  Regarding the GUI we have reasonable
doubts that it will be nice enough to meet the expectations of nowadays
users.

> If the Horde project will not come up with a polished GUI, ain't it possible 
> that kolab project adds this to the Horde project?  That way both projects 
> benefit, isn't it? 

That would be exactly the thing to do!  I thought that was what I
wrote... ;-)

> Building a GUI from the bottom up, is a hell of a job I imagine.

I don't know the current state of Horde-4, but yes, "a hell of a job"
describes very well what I expect to be necessary.

[...]
>> The suggestion has been made to take the administrative (web admin)
>> interface as a kind of playground to test out our capabilities of
>> creating an modern, appealing and user friendly web UI.
>
> I have always thought of moving kolab-webadmin into horde as that interface is 
> nicer, prettier than kolab-webadmin....

That's one possible strategy, which will be evaluated.

>> In any case this will be one of the more exciting areas in midterm Kolab
>> server development.  We are looking forward to your comments...
>
> I'm surprised that you're thinking of ditching horde.  Assuming that Horde-4 
> delivers what we expect ;)

Well, maybe you expect more than we do.  To make it completely clear: we
are just thinking, and we allow our self to think even of drastic
changes, as what we are longing for is a drastic improvement.  But no
decision has been made yet.

>> PS. Ok, it seems I failed in my attempt to give a _short_ report -- I'll
>>     try to be more concise next time...
>
> Thanks a lot for your post, it very much appreciated.
>
> Next time a blog maybe?  So it can be linked from major OSS news sites....  Or 
> is this http://kolab.wordpress.com/ your blog already ;)

To make a long story short: I'm no blog guy.  ;-)
And I like mail much better to carry on upcoming discussions than blog
comments.

Besides: I see the mailing list as primary place for developer
communication.  And its archived, so you can always link to interesting
mails (or the whole archive) if you like...

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20091118/5f6e2c5a/attachment.sig>