hey pierre, On Tue, May 03, 2005 at 04:24:42PM +0200, Pierre Habouzit wrote: > well, I guess my english is terrible. but let's take imp. au moins, je suis certain que tu peux parler anglais meilleur que je peux parler français :) > very often you want an imp.foo.org/ or a webmail.foo.org that points to > it (same for squirellmail and co). and default install is to be on > http://localhost/horde2/ IIRC, and is too restrictive, since it's not > the more common use, even if that's the easiest config. i believe that horde/imp do let you specify the subdirectory in which they exist, though you have to manually configure them (i just installed horde/imp on a box at work and istr something about this). even if it doesn't, there's always mod_rewrite or its equivalent. however, i know squirrelmail is really picky about this, maybe that's a better example? i haven't looked at the debian package but i know upstream makes it very hard to have the app in anything outside of a "src" directory. again, this could be worked around with some mod_rewrite voodoo i'm sure. > well, we know how to alias *one* instance of the webapp, not really many > instances on many hosts, without duplicating the code. sure we do. use multiple apache config files with different <VirtualHost></VirtualHost> blocks. likewise, you could do the same thing for multiple "installs" on the same vhost in different "directories". > take the webmail example, you may want a webmail.foo.org that serves > foo.org users, and webmail.bar.fr that serves only @bar.fr users. this > is unfeasible without patching the webmail. sure it is, you point it at a different database/config based on the vhost/directory it's in. > /srv/webmail.foo.org/[symlinks to /usr/share except vhost specific > files] > > /srv/webmail.bar.fr/[symlinks to /usr/share except vhost specific files] i think that doesn't really accomplish anything that couldn't be done in the http server configs. > > that's not true, most applications (at least ones that don't require > > daemons) do work on a per-vhost level, though the local admin has > > to do some work to get them to work. > > disagreed. the apps that have daemons (like the python servers that also > embeds their own http server) are vhost-aware and provide a global > config file, that is able to configure every single vhost. well, then you're furthering my point :). my concern with daemons is that the init scripts may not handle multiple instances of the daemon well. > no this is a real concern. extending include_path without any boundary, > will raise : > * performances issues (since to find an include you will have to scan > every single directory that is listed in the include_path) > * masking issues that are necessarily avoided if everything lives > in /usr/share/php. sorry, i meant in web apps, not in php libraries. the approach i mentioned makes sense in a web app, but not in a php library for exactly the reasons you mention. > > On Tue, May 03, 2005 at 01:50:04PM +0200, Pierre Habouzit wrote: > well, IMHO debian has not to package every piece of shit because it > simply exists. and let's be honnest, a lot of beginner programmers > write web apps, and those apps are written like shit. A webapp full of > code misconceptions will sooner or later : > * have bugs > * have security problems > * have annoying upgrade problems > and that will create burden on the shoulders of too many people. i think you and i share a common opinion of web applications :) the great thing about php is that it makes programming easy, even for non programmers. the horrible thing about php is that it makes programming easy, even for non programmers. another problem with webapps is that they tend to be rather volatile, which doesn't cooperate well with the debian release mentality. we should definitely have something (either developer's reference or policy) that advises how to handle backporting security updates in such a situation. in any case, i agree that in an ideal world we would be able to say, to be in debian, your php lib/app must do blah blah blah. however, i'm not sure that's possible, if only for political reasons. i guess it wouldn't hurt to try though. sean --
Attachment:
signature.asc
Description: Digital signature