[dev] [core] Content and Timeobjects

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>
>>>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>>>
>>>>> Quoting Chuck Hagenbuch <chuck at horde.org>:
>>>>>
>>>>>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>>>>>
>>>>>>> In an effort to firm up and simplify some things, the idea of  
>>>>>>> moving the functionality of Timeobjects into a horde-level api  
>>>>>>> calls and the drivers into a Horde_Timeobjects package was  
>>>>>>> proposed on IRC. Similarly, we also discussed the need to move  
>>>>>>> the core functionality of the Content psuedo-application into  
>>>>>>> a Horde_Content framework package. When it comes time for  
>>>>>>> thinking about URL endpoints for the content api, that could  
>>>>>>> be done via routes in horde-base. This alleviates confusing  
>>>>>>> custom configuration of registry entries for both of these  
>>>>>>> psuedo-apps, and would make it easier to use these libraries'  
>>>>>>> functionality separate from an actual Horde-app.
>>>>>>>
>>>>>>> Any input or concerns about this approach before we move on it?
>>>>>>
>>>>>> Quick response -
>>>>>>
>>>>>> 1. This should be discussed on the dev list, not the core list.
>>>>>>
>>>>>> 2. I did Content initially as a separate package because I'd  
>>>>>> rather we moved that way - towards drop-in bits of  
>>>>>> functionality - rather than towards more things in the horde  
>>>>>> base package. It was intended to be a framework package,  
>>>>>> though, not so much an "application". I'd like to move towards  
>>>>>> a system where packages that have controllers are automatically  
>>>>>> routable through some mechanism, but are still separate  
>>>>>> packages - not having to put everything like this in the base.
>>>>>>
>>>>>> 3. I don't follow the timeobjects proposal enough to have a  
>>>>>> reaction. Do you mean that there would be API calls on the  
>>>>>> horde base api for timeobjects? Why is that better? Seems like  
>>>>>> the same thing I was talking about in Content where we'd just  
>>>>>> be moving things into the base package...  but I may be missing  
>>>>>> the proposal here.
>>>>>>
>>>>>> -chuck
>>>>>
>>>>> For context, here is the IRC discussion we had:
>>>>>
>>>>> 1:38:30 PM mrubinsk: yunosh: now that we have a more consistent  
>>>>> solution with the install_dev script, should I add a registry  
>>>>> entry for the content package?
>>>>> 1:39:57 PM yunosh: in long term i rather want to see it  
>>>>> integrated in horde base, application wise. we could still  
>>>>> version it as a separate package for releases
>>>>> 1:40:11 PM yunosh: so in the end it shouldn't need a registry entry
>>>>> 1:40:24 PM mrubinsk: k
>>>>> 1:41:19 PM yunosh: do we use any application features like  
>>>>> registry calls ?
>>>>> 1:42:05 PM mrubinsk: nope
>>>>> 1:42:26 PM mrubinsk: afaik, right now the only thing using  
>>>>> Content is kronolith, and that uses the libraries directly
>>>>> 1:42:27 PM yunosh: i'm wondering why we need a registry entry at  
>>>>> all then? for the urls?
>>>>> 1:42:34 PM mrubinsk: for the include path
>>>>> 1:42:46 PM yunosh: ah
>>>>> 1:43:06 PM mrubinsk: I think chuck's vision was to have url  
>>>>> endpoints for a more RESTful api
>>>>> 1:43:27 PM mrubinsk: but right now, we use it kind of just like  
>>>>> any other or our libraries
>>>>> 1:43:37 PM mrubinsk: s/of/or
>>>>> 1:43:45 PM yunosh: yep, that's why i was wondering
>>>>> 1:44:44 PM yunosh: i guess we should discuss this with more  
>>>>> people soonish
>>>>> 1:44:51 PM yunosh: this also covers timeobjects
>>>>> 1:45:15 PM yunosh: it would work perfectly fine if we just  
>>>>> integrated it into horde
>>>>> 1:45:20 PM mrubinsk: yea, though with timeobjects, we actually  
>>>>> use the api
>>>>> 1:45:40 PM yunosh: sure, but we could add the api methods to horde base
>>>>> 1:45:46 PM yunosh: and the libraries to the framework
>>>>> 1:45:56 PM mrubinsk: ah?yea, that makes sense
>>>>> 1:46:16 PM mrubinsk: and for Content, just make it into a  
>>>>> library, and worry about the URL endpoints in horde-base when  
>>>>> it's time?
>>>>> 1:46:59 PM yunosh: i could imagine that chuck wants to chime in,  
>>>>> but for me that would work
>>>>> 1:47:31 PM mrubinsk: sure. I'll try to write up an email to  
>>>>> core@ in a bit, and we'll wait for chuck, and anyone else, to  
>>>>> chime in
>>>>> 1:48:00 PM yunosh: cool
>>>>
>>>> Okay. So my questions (#2 and #3) still stand. What's the reasoning?
>>>>
>>>> -chuck
>>>
>>> I would love to be able to drop in bits of functionality as you  
>>> propose. The initial conversation was triggered by me wanting to  
>>> put registry entries in for content and time-objects since, with  
>>> the new install_dev script, the pat is more predictable.  It was  
>>> then suggested to look at why we really need the registry entries  
>>> etc... the IRC log takes over from there.
>>>
>>> If whatever installation method we end up with allows for  
>>> automatic creation of registry entries/routes, then great, let's  
>>> do that. My motivation was to alleviate yet one more stumbling  
>>> block to setting up an initial development environment for  
>>> potential horde developers/contributors/testers etc...
>>
>> Okay. It sounds to me like adding the registry entries is the  
>> simple solution with what we have now, and eliminating the need for  
>> standard ones in the future is where we should go.
>
> Timeobjects is a different story though, because it doesn't have any  
> frontend and probably never will. It's really just a library, with  
> the difference that it needs a registry api to use it. That's why it  
> doesn't make any sense as a separate application.

On one hand, I can see the advantages of adding the listTimeObjects()  
API methods into horde base and moving the actual logic to a framework  
package. That was my initial feeling - it just "felt" like a better  
place for that type of functionality. After thinking about it though,  
that seems like the H3 way of doing things. If we are already heading  
towards being able to install bits of functionality (and even full  
applications) using PEAR or similar, and having part of the  
installation be creating appropriate routes/registry entries then I  
don't see why Timeobjects shouldn't be handled that way. That's what  
it basically is, a pseudo/mini/whatever app that provides some  
additional functionality...it just so happens that it provides that  
functionality by exposing API methods like a traditional horde  
application does.

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin