[dev] Horde 5?

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> I'm still currently against this, but am keeping an open mind. You  
>> do make good points, I just don't feel they justify taking such a  
>> radical step as splitting our repository. I'll obviously adapt to  
>> whatever the majority viewpoint ends up being. :)
>
> Something that hasn't been mentioned before: not all Horde libraries  
> are the same.  Things like Horde_Mime_Viewer, though theoretically  
> something that could be used outside of the framework, for all  
> intents and purposes will never be used that way.

Good point.

> But I do believe that other components would benefit from living in  
> a different codebase.  I don't know how well ActiveSync would work  
> beyond the rest of the framework, but that is a package that doesn't  
> exist anywhere else out there.  And I can guarantee that people  
> would be much more likely to debug/contribute if they had the  
> ability to only checkout that repo vs. checking out the entire Horde  
> codebase.

It can be used outside of the framework in the sense that all of it's  
dependencies are injected. That, of course, still means the libraries  
need to be available. It requires Horde_Exception, Translation,  
Support, Util and Horde_Db. It's probably safe to say that just about  
any Horde package would require most of those (the exception being  
Horde_Db).

> It has nothing to do with size/download times/etc. - it has to do  
> with complexity.  I know I immediately lose interest in poking  
> around a foreign repository if it is not immediately apparent what I  
> am looking for.

Agreed. Though I don't think having a monolithic repo makes this harder.

> I've always wondered if Imap_Client would get more support if I  
> moved it out into a separate repo that could be more visibly shopped  
> around.  That library is way better than any of the crapball IMAP  
> packages on Horde, and tons better than the duct-taped, feature  
> starved, performance deficient libraries other opensource PHP  
> webmail projects maintain.  At this point in the development, the  
> major issues tend to be broken IMAP servers, and this kind of  
> feedback necessarily needs to come from others since my personal  
> server usage is limited.

I understand your point, but I'm still confused as to why developers  
wouldn't use our PEAR package? What is the purpose of publishing them  
the way we do if we seem to be saying they should be using a Git  
checkout? Is it *just* to make installing the entire Horde stack  
easier? Not trying to be argumentative here, I'm just really trying to  
understand the difference in viewpoint. To me, Git and PEAR server two  
very different purposes.

As it seems I am obviously in the minority in wanting to keep the repo  
monolithic, I will cede the point and be resigned to the fact that we  
will eventually split it.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6096 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20120229/dd3a3af3/attachment-0001.bin>