[dev] [cvs] commit: incubator/minerva/lib Outcomes.php Recurrence.php api.php incubator/minerva/locale/sl_SI/LC_MESSAGES minerva.mo incubator/minerva/outcome ics.php list.php topay.php incubator/minerva/po minerva.pot sl_SI.po incubator/minerva/recurrence ics.php list.php ...

[Duck]

On Saturday 26 of May 2007 12:49:02 Jan Schneider wrote:
> This doesn't make any sense. Why would you want to convert invoices to
> dates to ics data, transport it over http and convert it back to
> events, if you can pass them directly to Kronolith?
>
> Horde apps use the internal api, anything else adds unnecessary
> overhead. Remote calendars are really for remote calendars, ie.
> anything not on the same Horde install.
>
> Of course you can still offer an external ics interface if you see any
> purpose for that, but please revert the replacement of the internal api.

In th first place I did this because this allows users to see invoice types in 
their local mail client directly from Minerva, which is better than calling 
Kronolith that calls Minerva.

Than with user experience we discovered that users don't like to see all 
invoice types together (invoice, recurrence, outcomes). List time objects 
actually don't allows to select what type of data we will like to see. Then 
for a user is much easier to just click on a link to add a calendar, than 
navigate from the “data api” to go to Kronolith, pass the preferences screens 
and go back to Minerva. So how to allow a user to select with data type to 
expose in listTimeObject? It must be simple as “Click here to add this data 
type to you calendars.”

PS: I will read the listTimeObect call with you last start/end parameters. 
Just give me a minute to make ma cup of coffie :)

Duck