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

List:       kde-pim
Subject:    Re: [Kde-pim] phpGroupWare
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-12-20 16:00:49
[Download RAW message or body]

On Wednesday 19 December 2001 18:07, Nick Papadonis wrote:
> Cornelius Schumacher <schumacher@kde.org> 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 <schumacher@kde.org>
_______________________________________________
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]