From kde-pim Thu Dec 20 16:00:49 2001 From: Cornelius Schumacher Date: Thu, 20 Dec 2001 16:00:49 +0000 To: kde-pim Subject: Re: [Kde-pim] phpGroupWare X-MARC-Message: https://marc.info/?l=kde-pim&m=100886421115494 On Wednesday 19 December 2001 18:07, Nick Papadonis wrote: > Cornelius Schumacher writes: > > > > Do you have some example code how to access a phpGroupware Server via > > XMLRPC? > > > > If there is a decent interface how to access the data on the server, e.g. > > creating a Korganizer plugin for accessing phpGroupware wouldn't be too > > difficult, I would guess. > > Cornelius, > > I think things like this would fit nicely into a KSYNC plugin as > follows (beat me in the head for not shutting up about this) : Sorry, for not responding to this. I did know that you would come back to it ;-) > DATA PROXY <--> KORGANIZER > > KSYNC <--> KORGANIZER PLUGIN > KSYNC <--> PHP GROUPWARE PLUGIN > KSYNC <--> PALM PLUGIN Could you please give some more details what kind of objects these are? Are these libraries, applications, servers, etc. and what kind of interactions the arrows represent (function calls, DCOP calls, server accesses). I'm not sure that I completely understand this diagram. > A simple syncronize click would syncronize the groupware server. Is this > desired, or is real time update desired from Korganizer as records > change? I think for a server solution real time access would be desired. This would eliminate the problems of syncing. It has to be made sure that the server responds fast enough and is always available, but in most local environements like an intranet this will be possible. > If anyone backs the above ideas, I have motivation to implement the > data proxy and integrate it with Korganizer. This would occur > over Christmas time off and right after New Years. Ah, a volunteer, that's great. > Things I would need input on: > > - Picking a database backend > * Is a server client database (PostgresSQL) desirable? > * Is a one hosted lightweight database (db) desirable? The databasse should be hidden and easily replacable by something different, so it shouldn't matter, which one you chose. > - Creating a schema for all the data we need to store > * What data does each application need to store? This is quite cleary defined by the relevant standards like vCard and iCalendar and represented in the classes of libkabc and libkcal. Once again, details of the storage format or method should be hidden. > I propose the following immediate milestones: > > - Implement the data proxy Sorry for being ignorant, but what exactly do you mean by data proxy, a subclass of Calendar, a stand-alone process or a completely different thing? -- Cornelius Schumacher _______________________________________________ kde-pim mailing list kde-pim@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-pim