faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
questions
by me on Friday 28/Jan/2005, @06:53
|
I'm really happy that there are finally some groupware solutions appearing for unix. Thank you very much for this interesting interview!
Still, I have some questions:
- There once was an idea to set up a kolab-server for the kde-community. One could integrate bugs, mailinglists, resources, todos, schedule kde-meetings and all that stuff. Also, one could probably stress-test kolab quite well with this setup. Why didn't this ever happen? Because of the costs?
- I understand that putting all data into a single database might be a little too much. But since I've never understood (and even grown to hate) LDAP, I am wondering why all the configuration-data that now lives in LDAP wasn't put into a database, like mysql?! What are the disadvantages?
- When I tried kolab at version1, it took me a couple of days to find out that the data stored with the kde kolab client is the same data that is accessed with the webinterface, but the outlook/toltec connector uses its own set of data and is NOT synchronized with the webinterface or the kde client. Thus, kolab1 was useless for me. I understand this has changed with kolab2?
In the second interview, I would really appreciate to hear about the synchronization plans. IMO, Syncing is one of KDEs really confusing areas. There are so incredibly many pieces of code meant to synchronize something (opensync, wince-sync, kitchensync, kpilot, multisync, kde-resources, kandy and all their friends) without a plan on how to bring it all together. Whats going to happen? |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: questions
by Kevin Krammer on Friday 28/Jan/2005, @09:24
|
> I am wondering why all the configuration-data that now lives in LDAP wasn't put into a database, like mysql?
I guess it depends on your LDAP configuration, there are SQL backends, arent't there?
|
[
Reply To This | View ]
|
Re: questions
by me on Friday 28/Jan/2005, @12:47
|
No, this hasn't changed with Kolab2. There is still no web interface which can access the same data like Kontact or Outlook which is probably mostly due to the concept which requires that any client keeps an offline IMAP4 cache of the complete data and per user.
So writing a web client is basically the same like writing a new groupware server from scratch _plus_ all the Kolab syncing stuff on top.
|
[
Reply To This | View ]
|
Re: questions
by Andreas on Sunday 30/Jan/2005, @08:53
|
This is nonsense. There is a webclient under development. Basic functionality is avaliable, but it will take time to complete the features. The webclient is able to access the same data as the other clients. Everything else would be against the concept to have one server accessibla with different clients.
|
[
Reply To This | View ]
|
Re: questions
by me on Sunday 30/Jan/2005, @19:38
|
The question was whether Kolab2 _has_ a usable webclient (one which works for more than 50 appointments in a folder), and it doesn't (if its in development for _Kolab3_, all the better!).
And apparently the development has stalled (a webclient needs to implement offline IMAP to be useful with Kolab and that is probably out of question for something like Horde).
Anyway, tell us if there is a webclient for Kolab which actually works in practice. The concept seems to be strictly focused on fat clients.
|
[
Reply To This | View ]
|
Re: questions
by Kevin Krammer on Monday 31/Jan/2005, @10:07
|
> a webclient needs to implement offline IMAP to be useful with Kolab
Why would that be needed?
The webserver is part of the Kolab service it has direct (over loopback interface) access to the other services such as the IMAP server.
|
[
Reply To This | View ]
|
Re: questions
by me on Tuesday 01/Feb/2005, @16:31
|
Because its part of the Kolab concept for clients, read it? Besides the IMAP4 protocol doesn't allow for range queries (like gimme all events from this monday to friday) as required for a web calendaring client, so live access is a no-go.
|
[
Reply To This | View ]
|
Re: questions
by Kevin Krammer on Wednesday 02/Feb/2005, @03:41
|
> Because its part of the Kolab concept for clients, read it?
No, that's why I was asking.
Might still be possible without, usually clients are on a remote machine where reducing network operations matters.
> Besides the IMAP4 protocol doesn't allow for range queries
Well, unless I am complete mistaken on what offline IMAP is, it is still IMAP, only using a local cache. All the query logic has still to be implemented on top of that.
So my guess is that caching greatly improves performance but is not necessarily required (technically).
|
[
Reply To This | View ]
|
|
Re: questions
by a.c. on Friday 28/Jan/2005, @16:21
|
>lives in LDAP wasn't put into a database, like mysql?! What are the disadvantages?
Nothing lives in LDAP, because LDAP has no storage. It is strictly an access protocol. LDAP allows you to change out the storage mech. . If you like you can use DBM, DBM, or flat-file, without changing the client or the protocol. If this goes down the DB path, then it is locked in. No scaling. No flexability. Think MS solution.
While I have not seen kolab2, kolab1 used imap to handle the sync. Good idea.
|
[
Reply To This | View ]
|
Re: questions
by Martin Konold on Tuesday 01/Feb/2005, @05:03
|
> - There once was an idea to set up a kolab-server for the kde-community.
> One could integrate bugs, mailinglists, resources, todos, schedule
> kde-meetings and all that stuff. Also, one could probably stress-test
> kolab quite well with this setup.
> Why didn't this ever happen?
Due to lack of resources (mainly a decent server with a good connectivity).
As soon as server plus bandwidth is available I am more than happy to provide a maintained Kolab Server to the community!
> - I understand that putting all data into a single database might be a little
> too much.
What kind of data are you talking about?
> But since I've never understood (and even grown to hate) LDAP,
> I am wondering why all the configuration-data that now lives in LDAP
> wasn't put into a database, like mysql?!
The biggest advantage of LDAP is that it is a network access protocol while MySQL is a product with proprietary protocol network clients. Another plus for LDAP in the Kolab design is that it features a simple, efficient and reliable replication protocol.
Using LDAP as the access protocol says nothing about the storage technology.
Actually most LDAP servers use some kind of (relational) database in the backend.
> What are the disadvantages?
Relational databases are incompatible to each other and many clients including Kontact, Mozilla, Microsoft Outlook and Lotus Notes know how to retrieve information like addressbook data via LDAP but they are not capable to talk to a MySQL db.
> accessed with the webinterface, but the outlook/toltec connector uses its
> own set of data and is NOT synchronized with the webinterface or the kde
> client. Thus, kolab1 was useless for me. I understand this has changed
> with kolab2?
Yes, with Kolab 2 all Kolab 2 clients (PHP, KDE, Windows) use the same new Kolab 2 storage format. Basically this new format is a set of iCalendar attributes encoded in valid XML including an XML Schema (Relax-NG).
The new storage format was intentionally created in order to allow for the usage with shared folders. Multiple different clients can have simultaneous read and write access to the same folder and its objects.
> In the second interview, I would really appreciate to hear about the
> synchronization plans. IMO, Syncing is one of KDEs really confusing areas.
I agree that synching is currently confusing. For the Proko2 project we limited ourself initially for syncing with the Palm Pilot for the KDE platform. With MS Windows/Outlook any existing OL-based synching solution keeps working so plenty of choices are available. We currently have no plans for synching support via the webclient.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
