[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] was: KSharedFile
From:       Ingo Assenmacher <ingo.assenmacher () post ! rwth-aachen ! de>
Date:       2001-12-11 19:01:59
[Download RAW message or body]

Hi.

Am Dienstag, 11. Dezember 2001 18:02 schrieb Cornelius Schumacher:
> On Tuesday 11 December 2001 00:35, Ingo Assenmacher wrote:
> >The source of the data could be handled by the broker
> > almost transparently to KOrganizer.
>
> You are proposing a calendar server, accessed via DCOP calls, right?

No. That is not my aim.  I wanted to sketch a solution for:
* a simple solution for a multiple-source for data approach
* Introduction of an active component that can be used not only by an 
Organizer view, but concurrently by another task (e.g. synching)
* a common interface for several data-units
* for the brainwave I had after too much work ;)

See, I looked into the code to see where the CalendarLocal-object was 
instatiated and was beriddled. I was thinking of transparently sneaking in a 
db-object without changing too much of the code. In addition I imagined that 
there might pe people out there who really wanted to use an existing 
Calendar-Server with a "real" protocol might be interested in integrating 
that kind of code. So I thought of a transparent solution to all connected 
entities. That was the purpose of the sketch.
Neither do I intend to use a calendar-server nor to invent one ;)

> I don't think that this is the right solution. If we ever implement a
> calendar server, we should make it a general thing using the existing
> standard protocols. 

Absolute agreement on my side.

> I don't see a need for inventing yet another
> protocol based on DCOP. DCOP is nice for some simple interprocess
> communication, but it's not the right solution for accessing data on a
> server.

As I stated: I do not know nothing really about it and its purpose. I just 
thought that is is there and that is has been designed for data-exchange 
between KDE-components.

> > I have read only minor things about DCOP and I am for sure no
> > KDE-expert. What do you think? Concurrent access would not be a
> > problem, as the broker could block/synch concurrent access.
>
> The main problem about concurrent access is not the blocking, but to
> make the clients capable of handling such situations as conflicts
> caused by external changes of the data.

Right, blocking was just an example. I see a solution in a controlled access 
to the data and a kind of active component that could notify registered 
clients after a data change so they can update their view on the data.

> Yes, as said before, a database backend for calendar data based on the
> Qt database classes would be great. But this would also mean quite some
> additions in the GUI parts of KOrganizer, so it will not be done on a
> weekend ;-)

I was not expecting this to happen over a weekend, that is why I try to ask 
and document my ideas so I can gather comments on this.
Thank you for your comment here.
I consider this discussion to be very fruitfull.

Regards, Ingo.
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
[prev in list] [next in list] [prev in thread] [next in thread]