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

List:       kde-pim
Subject:    RE: [Kde-pim] Resources framework
From:       "Best, Jan-Pascal van" <j.p.vanbest () tbm ! tudelft ! nl>
Date:       2002-11-12 14:47:21
[Download RAW message or body]

> > Although we're in deep-freeze for KDE 3.1, I'm thinking about the
> > new resources framework.
> 
> That's very good. I think this is the top priority todo item for 
> Korganizer after the release. It will give us multiple calendars like 
> in Apples iCal of Mozilla Calendar, it will give us the 
> ability to sync 
> calendar files without closing KOrganizer before, it will give us a 
> clean way to access servers like Exchange, Kolab or whatever.
:-)

> > I've had only two bug reports for the
> > exchange plugin so far: one was using an Exchange 5.5 server (added
> > more error reporting so that we can see so easier), the other one
> > never replied to me.
> 
> Good work. Do you think the plugin is ready for real use?
Apart from the two bug reports, I haven't heard from anyone using the 
plugin, so I can't really tell. "It works for me" may hide trouble
other might have.

The "Download" part is ready. The "Delete" part is also ready, although
it doesn't differentiate between recurring and non-recurring events, and
deletes the whole series anyway. There's a big fat warning in place, but
I
just noticed that it show everytime, not just when deleting a recurring
event.
This should be changed in 3.2: show a generic are-you-sure warning for
non-recurring events, and a special warning for recurring events. This
would 
cause maybe too many i18n string to change right now.
Or, better, fix deleting recurring events by asking whether to delete 
the occurrence or the entire series...

About the "upload" part: I think it's ready. Maybe we should rethink the

warning message that pops up now when you upload an event to the server.
It says
"Exchange Upload is EXPERIMENTAL, you may lose data on this
appointment!",
which was true written when the warning was written, but not so anymore.
We might want to remove that warning.
I don't know of any situation that would cause data loss, but of course 
there might always be a bug that causes it. And since I've had
essentially 
no feedback from actual users...

> > So, for the future, here is the current state of the design document
> > for the resources framework.
> 
> I just read it and I have to say that what you write makes 
> perfect sense 
> :-)
<blush>

> > Right now I'm working on (1.). Communication via DCOP 
> between several
> > instances of ResourceManager(Impl) is working well: they notify each
> > other of e.g. a new resource via DCOP. The receiving ResourceManager
> > then reads the details of the resource from the configuration file.
> Sounds good.
One thing remains, as you mentioned earlier: several KDE sessions
can use the same configuration files, but have separate dcopd processes.
Maybe we can somehow connect to all other dcop daemons sometime.
It's not high on the list however.

[snap: no signals, but Listener class for ResourceManager]
> Yes, that would be an implementation of the Observer design pattern. 
> There already is another one in libkcal for notifying changes 
> of events 
> to the parent calendar object. It's the same problem, the 
> events can't 
> be QObjects, so an alternative way of signalling has to be used. The 
> Observer works quite well.
Yep, it now propagates changes in another process's ResourceManager
down to the MultiCalendar. Only KOrganizer still won't listen ;)

> > Any more comments on the way this framework is going are also
> > very welcome!
> 
> - I don't see, why the ResourceManager has to be a singleton. There 
> might be applications where it could make sense to hold different 
> instances with different parameters. The KArm example would be one of 
> them. As ResourceManager objects are probably only used in a small 
> number of classes this seems to be the cleaner solution anyway.
You're right, it doesn't have to be any more. And I'm also thinking
that the list of active resources should be defined per application,
not globally. I've removed the singleton stuff already.

> - Please remove the fastResource parameter from the Resource 
> API. This is too specialized and too misleading.
You're right, got rid of it.

> - The static crypt functions probably belong to KApplication 
> and not to Resource.
Either there, or some other semi-global place. We'll ask the 
KDE gods after 3.1.

Cheers

Jan-Pascal

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]