[dev] [core] Content and Timeobjects

Thu Jan 7 00:15:39 UTC 2010

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.
Content is not the same, agreed, because it has a frontend. Though I  
wonder if we should really bother keeping it separate as long as we  
don't use that frontend, and don't foresee any short-term usage either.

Jan.

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