[dev] [cvs] commit: incubator/minerva/lib Outcome s.php Recurrence.php api.php incubator/minerva/locale/s l_SI/LC_MESSAGES minerva.mo incubator/minerva/outcome i cs.php list.php topay.php incubator/minerva/po minerva .pot sl_SI.po incubator/minerva/recurrence ics.php li st.php ...

[Jan Schneider]

Zitat von Duck <duck at obala.net>:

> 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.”

Whups already has a method for selecting the time object types to be  
returned to Kronolith. We only need to extend the preference in  
Kronolith to use these time object types. The same could be done for  
Minerva then.
I agree that having the users to go to Kronolith to set a preference  
to receive time objects from Minerve is not very elegant. But that's  
exactly the reason why Chuck changed your calendar/subscribe patch to  
not only except remote calendars, but also internal api calls.

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

Great. It's not (yet) technically necessary, but it will reduce the  
amount of data shuffled from the apps to Kronolith.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/