[dev] [commits] Horde-Hatchery branch master updated. d3fcd5cdd11ada51d44c03fccd529ba9beed543d

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> If you mean the fact that there would not be a default index.php at  
>> the base of the webroot, e.g. http://www.example.com/index.php  
>> (since horde would be installed in http://www.example.com/horde/),  
>> I think this is completely irrelevant.  It is my strongly held  
>> belief that there is no reason why we should make the git repo a  
>> "drop-in" installation of horde.  If someone does wants to run  
>> using the git repo (realistically, this will be a handful of people  
>> - and those people will mostly be horde devs), they either have to  
>> accept that the apps won't live underneath horde or they will have  
>> to manually symlink the directories.  Again, not a big deal.
>
> This is not what I'm talking about. Please remember that this thread  
> was about whether we want to distribute horde in the future like we  
> did before, i.e. expecting the users to install the apps *inside*  
> horde/, or change to have them install the app *next* to horde/.
> If we opt for the latter, it's only a side-effect that this also  
> matches the layout of our git repository. This helps because we can  
> use the same registry.php for a dev git checkout and a release, and  
> we don't have to symlink anything.

And this is what I find unacceptable.  Determining how 99% of users  
install the applications should not be decided by the ease of  
installation for the small handful of people that may run the  
application directly out of a git checkout.

Whether we want to ship with applications under horde or in separate  
directories is an important and valid question.  However, the way the  
code is stored in our repository (due to technical limitations) must  
not be the deciding factor.

As far as I see it, here is a quick list of pros/cons:

Live under horde/
-----------------
+ Historically the way we have done things
+ Easy to determine paths (no extra config needed)
- No flexibility in layout

Live in separate dirs
---------------------
+ The way our repo is stored
+ Maximum flexibility for admins
- Extra config needed to determine paths (can this be automated by installer?)

>> That being said, it would be trivial to add an index.php file at  
>> the base of horde-git that simply redirects to horde/index.php.
>
> That might help, though I'm not sure this is going to be the best  
> solution. I can't think of a better one right now though. Including  
> horde/index.php would help obviously because paths don't match  
> anymore.
>
>>> We can add one to the base folder of horde-git, and also to the  
>>> groupware bundles, but how are we going to provide one when we we  
>>> distribute the modules separately, whether as a pear package or a  
>>> tarball?
>>
>> Still confused as to what you think is missing in a package/tarball.
>
> Still the base index.php. People unpack horde, and point the browser  
> to the base directory of the unpacked tarball. This has to work  
> out-of-the-box. If the start page is not in (e.g.)  
> groupware/index.php, but groupware/horde/index.php, it doesn't work.  
> Thus we need a groupware/index.php.
> It's not a problem to add such a redirect index.php to the groupware  
> bundles and/or the git base dir, like you pointed out above. But  
> what about the people that don't install any of those, but each  
> module separately.

I absolutely do NOT want to cater to the tiny fraction of people that  
may download imp (for example), extract it in a web-accessible  
directory, point their browser at that directory, and then get errors  
that various horde core libraries/paths can not be found.  If these  
people can not take the 5 seconds to read INSTALL, they don't deserve  
to run the software.  Period.  We (as devs) have much better things to  
focus on.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]