[dev] [core] Content and Timeobjects

[Chuck Hagenbuch]

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