[dev] [core] Content and Timeobjects

[Michael J. Rubinsky]

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


-- 
Thanks,
mike

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

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.