Re: [eGroupWare-core] Addressbook xmlrpc comments. (Warning: Quite Long :-)

[Carsten W. <car...@cr...>]

On Saturday 09 July 2005 20:01, Miles Lott wrote:
> I was only trying to say that an xml-rpc session works the same way as a
> browser session with regard to user data (prefs, acl, etc.)

sure

> Ideally, the ui layer is not massaging data beyond what the bo layer
> provides, so that xml-rpc receives the same data as the browser.  It
> might be preferable that the ui layer only makes bo and ui-relevant api
> calls, for that matter, e.g. template/html classes.  This would ensure
> that the bo layer is already setup to return the data of the same value
> as is displayed in the browser.  For example, the format of a date value
> might be different in the ui, but the actual date should be the same
> coming from bo.  If we can agree on this, it makes sense to also
> standardize returns for add(), etc. between apps.

Right. Yes, I thought about that conflict, too, before. Of course, ideally,=
=20
the bo-layer should never act differently depending on which client does a=
=20
call. But as it is in calendar, where bo returns times in server-timezone, =
an=20
xmlrpc-client has no chance to determine, how it can convert it to the=20
clients timezone. It just doesn't know to which timezone the time it reciev=
es=20
belongs to. So either there needs to be a way to read out the=20
server-timezone, or all times need to be guarenteed GMT.
=46iguring out, how to do this without hurting the layer-concept to badly, =
is an=20
implementation detail.

> It's probably a never ending argument with regard to stored vs.
> displayed date information.  But it would be nice if all apps stored
> data (so layer) in the same timezone (GMT), then the bo layer can adjust
> for the user timezone as desired.  UI or the xml-rpc client can then
> format it however they like and perhaps based on user preference.

That is, if the xmlrpc-client knows about the users timezone.

> Btw, when I say API I usually mean phpgwapi.

OK, I just wanted to make clear, that there are other APIs in eGW, too and=
=20
that it is not clear for any of them (including phpgwapi), if they should=20
stay stable (i.e. source compatible) for the next release.

Carsten

=2D-=20
THE K Desktop Environment:  http://www.kde.org  wo...@kd...       =20
My very own little site:    http://www.wolffcarsten.de