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

Tue Nov 17 22:47:03 CET 2009

Hi,

Op dinsdag 17 november 2009 16:36:21 schreef Sascha Wilde:
> with this mail I want to give a short report at the current plans and
> ideas for Kolab Server and results from the meeting Gunnar, Thomas,
> Bernhard (Reiter) and I had last Friday.
>
> Originally I would have loved to write this mail earlier and I would
> like to write mails like this (giving some sort of Kolab Server related
> "Brain Dump of the Week") way more often, but there is this little
> thingy from the subject: reality (you know, it bites)...

Very good.  Almost like a blog :)  When is planet.kolab.org going to arrive ;)

> Anyways, whats worth reporting?
>
>
> 1. Release Plans

skipped this part.  Looks like it is in good hands.

> 2. Packaging and Distribution Future
>
> The current official and only commercially supported platform for Kolab
> is OpenPKG -- unfortunately the future of OpenPKG, technically and
> politically (read business model), is unknown -- at least to us.  On the
> other hand there is the contributed native packaging of Kolab server for
> many distributions, with varying grades of functionality and stability.
>
> Currently we are not sure what to make of all this.  It is clear that we
> will continue to need one defined distribution with stability and
> support standards for our enterprise business -- but this might not
> necessary be OpenPKG for ever.  Besides this we want to make Kolab
> server as attractive and easy to setup for users and developers as
> possible, which not at least would mean to support good native
> packaging, but once again the strategy how to achieve this with limited
> resources is work in progress.

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.  Different rpm distros, but 
at the same with the same sources and in the same repository, packages can be 
build for deb based distributions like: Debian and Ubuntu!  The build service 
uses 1 spec (and a deb control) file, to build packages for different versions 
and architectures of the before mentioned distributions.  The result can look 
like this:
http://download.opensuse.org/repositories/openSUSE:/Tools/
or especially kolab related:
http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/

The build service is made so people can Kollaborate in building packages.  The 
service can be accessed with a command line client, that works like cvs / svn.  
But at the same time there is a web interface available.  It all works rather 
intuitive and is very user friendly :)  and oh, the builds can be tested local 
first, and if all works fine the changes can be committed to the repository.

If that is not enough the end product are not only packages, it is also 
possible to define an image (called kiwi) for a live Disc or memory stick.  To 
test the build service you need to ask for account on the build service.  
After that I can e.g. add you to the Kolab repository as maintainer.  The 
sources for the build services are fully open source and packages can be 
downloaded from the build service.  So it can also be used "in house".

openSUSE (being the payed engineers of openSUSE and the community packagers) 
uses it to build its entire distribution with it, hence it is very well 
maintained.

I really hope that you have a look at this superb service, it's very powerful 
and it is a relieve to be able to build packages for many distribution 
versions at 1 time.  More information can be obtained from:
http://en.opensuse.org/Build_Service or from me ;)

> 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.

> 3. The Web Client
>
> The current web client was a big step forward as it finally gave all
> those who can't install an native Kolab client on there systems the
> opportunity to joint he happy community of Kolab users.  But lets face
> it, the current web client is no beauty queen and the user experience is
> not comparable neither to the native clients, nor to the fancy web
> clients of other systems (have you seen the zarafa client?).
>
> Well, we had some talking on this and basically we all agreed that we
> need some major improvement on this sector (which btw. includes the Web
> Admin interface and the Free Busy View, too).  Currently the discussion
> is open what the best strategy for the future will be, basically there
> are two major options:
>
> - 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?  Do you mean that the Horde-4 
won't provide e.g. the Silver theme (the one that kolab-webclient uses now)? 
What is the current state of Horde-4?  Will it be available in 2010 (what 
quarter).  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.

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?  Building a GUI from the bottom up, is a hell of a job I 
imagine.

> - Alternative: ditch Horde for the web client part (we would keep some
>   horde parts for the server functionality like Kolab Filter and Free
>   Busy) and pull another, more fancy free software web client into the
>   Kolab project.  This would of cause mean to heavily extend what ever
>   candidate would be chosen, as currently none of the other web clients
>   offers even near complete Kolab support...
>
> 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....

> 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 ;) Horde-4 provides a nice and good webinterface to 
the kolab server almost for free.  So, put at least the effort in getting 
Horde-4 connected with the kolab server, and maintain.  After effort can be 
put into another fancier webclient.

> 4. More to Come
>
> Finally there are some more exciting thing going on behind the scenes
> which I can't tell you about currently -- stay tuned!  ;-)

I do :)

> That's all folks!
> cheers
> sascha
>
> 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 ;)

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20091117/c87b0bd4/attachment.html>