On Wed, Nov 04, 2009 at 09:48:25PM +0100, Jan Hauke Rahm wrote:
> > Now, written this way, it looks harder to implement, because it is a
> > kind of overlay over a default docroot (unless we assume the default
> > docroot is read-only for the sysadm, which doesn't look reasonable).
> Right, either the admin can (and will) write to the DocRoot (which was
> meant to be reserved for the package manager), or we need two DocRoots
> configured which I don't think is possible with common web servers.
... or we find a technical way to enforce a kind of overlay, which is
what the two alternative solutions I advanced try to do.
> > - either the final URL is something like
> > http://localhost/debian/package/ (replace "debian" with whatever
> > prefix you like) and have some other per-web-server mechanism take
> > care of adding an Alias/link/whatever from "debian" to that new static
> > doc root
>
> Like all packages drop their files in /var/lib/www/package and some
> default package (or the web server itself) drops a symlink
> /var/www/debian -> /var/lib/www ?
> This would again lead to at least one file name in the sysadmin's space
> that he/she can't use which is what we try to avoid in the first place.
Well, everything is not black or white, we are not really forcing
anything on the sysadm. First of all it is just one file and only for a
single vhost in the default configuration (not in all possible
configuration the sysadm might prepare later on), and finally for all
web servers that support Alias-like directives it is not even a file: it
is just a config line that can be easily commented out.
> > Assuming that web servers can register themselves to the mechanism,
> > that would also solve the problem that webapp maintainers not
> > necessarily have the knowledge of the syntax of all available web
> > servers
>
> You mean like a trigger that is dealt with by any web server installed?
Yes, exactly.
> Actually, I don't see a way to implement that (but then I'm probably not
> the best code writer). It would be really nice if the web servers could
> somehow register themselves for this but I think in the end this is
> really what webapps-common was aimed at, isn't it? Except the
I believe so. If we go forward with that, that would be a first step
toward uniforming the packaging of webapps, whether it is called
webapps-common or not I personally couldn't care less.
> self-registering of web servers webapps-common could solve this all. A
> package build-depends on it and gets provided with necessary
> post{inst,rm} lines to register with known web servers. Considering that
> there are that many web servers in the archive, it should be managable
> for webapps-common maintainers to keep up2date with those.
No, not really. With webservers registering themselves I was thinking at
something like each maintainer of a webserver package providing a script
(which a specified API which is the same for all webservers). That
script will be in charge of mapping one generic Alias directive (coming
from a single webapp package) to the way of implementing that directive
in the specific webserver. This way the webapps-common infrastructure is
no longer in charge of maintaining neither the knowledge nor the
implementation of every single webserver, it is only in charge of
maintaining the generic infrastructure.
> So, after all I think we need some manpower in webapps-common and we
> have a solution. Or not?
That's out of doubt :-)
> > Many thanks for sharpening the analysis, Jan.
>
> You're welcome, although I prefer to be called Hauke. I'm a
> middle-name-user ;)
Ooops, sorry :-/
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature