[dev] apis: next steps

[Chuck Hagenbuch]

Quoting Karsten Fourmont <fourmont at gmx.de>:

> 1) Nag: due to new fields in NAG, the add() and modify() functions now
> have very long parameter lists. I'd like to change them to accept hash
> arrays like the other apps do to. Positive side effect is, that api.php
> does not need to be changed when adding new fields and can thus the
> same code works for HEAD and FRAMEWORK_3.

Instead of this, I'd prefer to go ahead and introduce a Nag_Task class  
(like Kronolith_Event) to encapsulate task objects. Much cleaner that  
way.

> 2) I'd like to (manually) merge the latest bugfix changes from api HEAD
> to FRAMEWORK_3.
>    Namely:
>     - no longer use option arrays. They never really worked

As long as nothing relies on this, fine. If any other code besides  
syncml used it, then this shouldn't be done in HEAD either.

>     - fix handling of different sources

Sounds reasonable.

>     - turba: use correct delete function

Definitely.

> 3) for removeUserData: call removeByParent if possible, otherwise
>    work around it. S.th. like this:
>    if (method_exists( $history, 'removeByParent') {
>        $histories = $history->removeByParent('mnemo:' . $user);
>    } else {
>         $all = $history->getByTimestamp('>',0,array(),'mnemo:' . $user);
> 	$histories->removebyNames(array_keys($all));
>    }

The 2nd option needs to be implemented for both HEAD and, if merged, FW_3.

>    As $all can get quite big removeByParent is still preferred.

Yup. It'd actually be best, BC- and performance-wise, to add a local  
class that extends History and adds the needed method to each app that  
needs it. A pain, but the only way to handle both overall.

-chuck

-- 
"we are plastered to the windshield of the bus that is time." - Chris