kronolith/lib/api.php missing function in wsdl

the documented function _kronolith_modified(string uid) isn'

Thu, 14 May 2009 11:40:22 +0000

the documented function _kronolith_modified(string uid) isn't exposed by webservice @line 81 + $_services['modified'] = array( + 'args' => array('uid' => 'string'), + 'type' => 'int', +); @230 +function _kronolith_modified($uid) +{ + return __kronolith_modified($uid); +}

Where is it documented?

Thu, 14 May 2009 17:46:05 +0000

Where is it documented?

This method is documented in http://dev.horde.org/api/kronol

Fri, 15 May 2009 09:06:03 +0000

This method is documented in http://dev.horde.org/api/kronolith/Kronolith/_lib---api.php.html and I think should be exposed here and in other modules. imho retrieving the modify timestamp of one item should be done with a single call, no matter whether the item were added or modified. as of now I have to invoke twice getActionTimestamp: - first with modify - then with add Imagine in a tree I got 20% new items, it's 20% more calls...

> This method is documented in > http://dev.horde.org/api/

Fri, 15 May 2009 14:21:25 +0000

> This method is documented in > http://dev.horde.org/api/kronolith/Kronolith/_lib---api.php.html and > I think should be exposed here and in other modules. Of course it is documented there, the API docs are generated automatically. That's not a reason to expose this method though. > imho retrieving the modify timestamp of one item should be done with > a single call, no matter whether the item were added or modified. > > as of now I have to invoke twice getActionTimestamp: > - first with modify > - then with add You need that information separately for your purposes anyway, because you want to announce changes and additions in separate SyncML messages.

> You need that information separately for your purposes any

Fri, 15 May 2009 14:35:41 +0000

> You need that information separately for your purposes anyway, because > you want to announce changes and additions in separate SyncML messages. it's not about syncml. writing a funambol backend you need to provide a "strategy" of managing items. then funambol converts your strategy in syncml adapting all the communication to the client capabilities with a series of parachutes for misbehaving clients. what is done is: * create a map of all items stored on horde * then manage this map to retrieve new,updated,deleted items. anyway: * being this function implemented, I see no reason not to expose it: it's definitely useful ;) * I'll be glad to discuss those stuff with you by mail...maybe the buglist is not the best place...

Changes have been made in CVS for this ticket: http://cvs.h

Tue, 16 Jun 2009 12:54:49 +0000

Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/kronolith/docs/CHANGES?rt=horde&r1=1.165.2.262&r2=1.165.2.263&ty=u http://cvs.horde.org/diff.php/kronolith/lib/api.php?rt=horde&r1=1.126.2.61&r2=1.126.2.62&ty=u

Convinced.

Tue, 16 Jun 2009 12:55:14 +0000

Convinced.

Changes have been made in Git for this ticket: Propagate th

Wed, 13 Jan 2010 00:05:08 +0000

Changes have been made in Git for this ticket: Propagate the 'modified' API method (Request #8274). http://git.horde.org/diff.php/kronolith/docs/CHANGES?rt=horde-git&r1=d9291a87caf42bbf85bb0ff7767934e4bce1003f&r2=24813c63d8759acf39e2f4789512f595c699c3df http://git.horde.org/diff.php/kronolith/lib/api.php?rt=horde-git&r1=ebdfffb4b98e9be51d55c8a400d29247c3ed10b7&r2=24813c63d8759acf39e2f4789512f595c699c3df