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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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.

As I said, this would be a side-effect. If the repository matches the  
layout of the later releases, great. At no point I made a case of  
changing the release layout because it should match the repository.  
The exact opposite is what I'm talking about.

> 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.

And no one talked about that.

> 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

And from earlier of this thread:
+ Easier packaging (don't need common parent directory)
+ Easier administration (backup, copy, move, test)

> 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?)

Why do we need an extra config? As long as we suggest to place all  
modules in the same common parent directory, we know the paths too.

Also, from earlier:
+ Simplify some maintenance/building scripts
+ Better compatibility with distribution packages

>>> 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.

Who was saying that? This never worked in any version, and we of  
course we can't help people that don't read installation instructions.

But that's not what the index.php is about. I brought this up because  
in the last message before I re-started the thread, Chuck suggested as  
a solution for the bundles, and if having horde next to the apps, to  
include everything in another base directory. This is where the  
index.php is required. But also if people install the modules  
individually. Because they want their users to go to  
http://webmail.example.com/, not http://webmail.example.com/horde/.  
And this is btw another disadvantage of having horde next to the apps:  
I'm sure some admins will complain that "horde" now always shows up in  
the url.

Jan.

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