HEADS UP for maintainers of web applications

[Clement Laforet]

On Fri, May 12, 2006 at 01:25:22PM -0700, Doug Barton wrote:
> > I believe this decision was made by Apache port maintainer (clement)
> > some months ago.
> 
> With due respect to Clement, I don't see his maintaining the apache ports as
> giving him authority to dictate how those directories are used, or how other
> applications get installed.

I totally agree. I don't have the power nor the wish (even with my 
portmgr hat) to unilaterally impose those changes, but I think we 
should face the real problem: we don't have a decent framework for web 
stuff. I'm conviced we need a "webbase" port which include hier and 
some promotion stuff (a standard default page) and few 
FreeBSD images/icons/banner.

Why bother?
+ Unlike linux distros, ports provide a large variety of
  configurations.
+ 
- People usually manually alterate server config files.

                  +--- apache 1.3---+
                  |                 }--- mod_php -------+
                  |                 |                   |
+-------+         +--- apache 2.x---+              +----------+
|webbase|=========|                 |==============| web apps |    
+-------+         +--- lighttpd ----+     CGI's    +----------+      
                  |                 | (perl/php/...)
                  |                 |
                  +--- cheerokee ---+
                  |
                  +   (........)    +

Layout               HTTP servers                      Apps


> >>> All web applications should be now installed into ${PREFIX}/www/appname.
> >> Why? What benefit does this give us, and what was the cost of doing it the
> >> way it's been done for a long time already?
> > 
> > It gives us consistency.
> 
> "A foolish consistency is the hobgoblin of little minds."  -Emerson

None is a nest of bikeshed.

You also mentioned that some people tried to "clean" www/ but it 
desperatly fails. I perfectly understand the logic behind our 
good-old-www-layout, but it's cgi-based. Now many apps are self 
contained. If I were a newbie, I'd surely be desappointed to discover
I can't use horde, and phpSysInfo without changing apache conf or read 
cryptic Makefile.

But I know that it doesn't solve all problems. It's just a start and 
rises many issues:
Which default DocumentRoot to use? Why should we keep cgi-bin, icons, 
etc. directories outside of DocumentRoot when some webserver don't 
support aliases? and more...


> > Up until now, every maintainer installed the
> > files where they seemed fit.
> 
> How DARE those wily maintainers actually exercise some free thinking!

:-)

> > With this policy, user can reasonably
> > expect to find newly installed app in predictable place.
> 
> In some cases, this is a virtue, but in many others it adds complexity where
> it's not needed. I maintain a moderately complex web based application that
> installs things in:
> $PREFIX:
> bin/
> etc/
> include/$appname
> lib/$appname
> share/doc/$appname
> share/$appname
> www/cgi-bin
> www/data
> www/icons/$appname
> 
> I have gone to great pains to make sure that my application works for the
> user right out of the box. No modifications to the standard apache conf file
> are needed, no symlinks are needed, nada. The change you suggest would
> violate POLA for just about every aspect of my port, not to mention creating
> an upgrade nightmare for its users. Please explain how this is useful or
> beneficial to them.

Technically it just impacts DocumentRoot. If I take textproc/htdig, 
since you maintain it, only --with-search-dir would be changed.
As I previously said, only server accessible part should be put in 
${PREFIX}/www/${appname}, many php apps already use this layout.
Due to variety of web accessible applications, it's hard to find the 
"universal" layout, but doesn't mean we don't have a minimum of 
consistency, and I don't think it's this one is foolish :)

To avoid POLA, we can rely on a WWW_DOCUMENT_ROOT variable, instead of 
hardcoded {'www/','www/data'}/${PORTNANE}. I don't mind which document 
root we should use, www or www/data. I prefer www/${PORTNAME} because 
most of I webapps I ported where put here.

> > It gives us independency from Apache.  People may want to use their web
> > apps on top of lighttpd or any other web server.
> 
> Once again, change the newer applications that have a smaller user base to
> use the FreeBSD standard directories. That's what the ports tree is for.
> This "independence from apache" is a completely specious argument. Those
> directories mean what we say they mean, regardless of how and when they are
> installed.

I object. PHP is now apache-free, so let's deal with it.

We also have to avoid conflicts betwwen apps too. Forcing to put 
serviceable pages (except cgi-bin) in ${appname} subdir reduces 
chances of conflict and so, are webmaster-friendly. Who is the 
maintainer dare to pollute DocumentRoot because it installs generic 
named pages, like footer.html or header.html?

> Since I started maintaining ports, this is either the 4th or 5th attempt to
> remake the www tree into someone's uniquely skewed view. It gets really
> boring after a while.

I agree. Let's fix it now. What do you like to see 
kept/removed/reconsidered. I'm sure we can find an elegant way to fix 
thoses issues:
- We're apache centric and rely on its www hier
- PHP apps relies on php not the webserver running them
- We don't have consistency in serviceable pages path. Let's choose 
  one. It's sutpid to annoy end-users longer. 
- and many more...

clem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20060513/144cb629/attachment.pgp