[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>:
>
>> Let's give this discussion more speed, because now that we don't  
>> have hatchery anymore, if we decided to run horde side-by-side with  
>> with the apps, we can drop the install_dev script again, and use a  
>> horde-git checkout as the webroot, symlinking the framework  
>> packages like we used to.
>
> I assume with this approach you would be changing the paths in  
> registry.php to point to applications.

Yes, sure.

>> When I thought about this, I found another problem with this  
>> approach though. If the apps are not installed inside horde/, we  
>> don't have a default index.php anymore.
>
> I am confused by this statement.  What do you mean by "default  
> index.php"?  For each application?  Each application should have an  
> index.php defined, so that should not be an issue.  For applications  
> requiring separate auth, like imp, accessing index.php within the  
> imp directory will redirect to horde's login page.
>
> 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.

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

>> Maybe we could make the horde tarball containing such a index.php  
>> and the horde/ directory only, at the top level. This may be hard  
>> to package with pear though, because with pear you can't package  
>> files that are a directory level *above* package.xml. I'm not sure  
>> if the same restrictions apply to pyrus.
>
> Again, still confused as to what the problem is here.  My  
> understanding is that groupware bundles will continue to be  
> distributed with the apps living underneath horde/.  And the vast  
> majority of users installing applications individually from tarballs  
> will do the same thing.

No, this whole thread was about *not* doing this anymore. Or actually  
it was about whether we want keep doing this or not. We still didn't  
agree upon one or the other, that's why I revived it.

Jan.

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