Re: A few selected thoughts....

[Joakim Ziegler <joakim ximian com>]

On Tue, Mar 06, 2001 at 08:54:40AM -0500, digitect wrote:

>> 2. "Interests" and things like that.
>> This seems like it would just be a links page.  The first thing that I
>> would say is: do we want a links page?  I would rather see relevant
>> links to outside sites appear in context.  I'm sure that we can
>> incorporate everything that one could want in an interests section in
>> the various sections that are relevant.
 
> I think its helpful to have a resources section. Unless we're trying to
> be exclusive, a thorough listing of other sites is actually helpful in
> bringing traffic in. People will think, "I can't remember that
> site/project/organization but I bet the GNOME Resources page has it."
> (Back in my User section days, I also though it would be good to have a
> separate User resources, too.)
 
>> 4. CSS
>> I'd ideally like to use CSS for pretty much everyhing.  Of course,
>> we're going to have to support broken browsers, so I agree with Joakim's
>> thoughts on doing some browser detection for broken CSS support.
 
> I feel like discussion of the delivery system for both form and content
> will inform if/how we use CSS. Is that the next step?

Yeah, I'd say so.

My idea of how to do the templates and so on are as follows. This is based on
stuff I've done before with PHP, and is very close to how we currently do
things at Ximian, for instance (we also use PHP templates and manage our
website out of a CVS module), and I think it's a pretty decent balance
between flexibility and consistency.

Templates and template functions:

The page includes a main include file that includes all other includes (makes
it easy to add to). The includes are full of functions that define all the
layout actions, are self-contained, and usually come in pairs or triplets.
For instance, there's a page_start() and page_end(), if there are boxes on
the page used for formatting, there's a box_start() and box_end(), if the
boxes have a separator built in, there's a box_separator() that can be used
between box_start() and box_end(), and so on.

Functions are as much as possible built from smaller functions, if it's
conceivable that these functions might be useful in several places. Of
course, if you've done some programming, this is familiar ground.

The directory structure closely mimics the navigation structure. This allows
us to do very efficient tricks using path name analysis to figure out where
in the navigational hierarchy we are, and to highlight menus and so on based
on that.


The browser dependent content stuff I talked about:

I'd be happy if we could use browser dependent data delivery through PHP.
This can be used both to give a table-formatted page to browsers that can't
handle CSS, and a nicely formatted text version for Lynx, etc. Additionally,
we can use it to deliver .gif or .png (or .jpg for that matter) files
depending on what the browser will accept. This will work a lot better than
the Apache content negotiation we currently use, since that depends on the
same filename being requested for both PNG and GIF, and thus Apache finds it
necessary to specify a no-cache pragma, which has led a lot of users to
complain that the site is slow, because they reload images more often than
they normally would.

I'd also like to keep duplicate PNGs and GIFs out of the CVS module. It's
easy to write a little PHP bit that converts the PNG to a GIF the first time
it's used in a page, and then caches that for later use.

To achieve this UA-dependent content delivery is easy if we use template
functions like the ones I describe above for all non-trivial layout (anything
beyond simple bolding and paragraphs in the text should probably use
functions). The page_start() function, which must always be called, can do
the tricky browser detection stuff according to a lookup table, and set a
couple of global variables that can be used in all other functions to very
quickly see what version of the data should be output.


Performance issues:

PHP isn't slow, as long as you take care with what you're doing. We've used
most of these techniques at Ximian already, and that webserver is rather
modest hardware, yet handles 20 hits per second and more during peak times
(and it doesn't even serve images, only pages, since Akamai does images for
us).

There are a few rules of thumb that are good to know about PHP4 performance,
I'll quickly outline them for people who want to help implementing:

* Function calls are extremely cheap.
* includes are cheap enough, as long as there's not an extreme amount of them
  (if you're doing more than 10 includes in total on an average page, though,
  you might be doing something wrong).
* stat() type operations (getting a file datestamp, checking if a file
  exists) are very cheap.
* Actually opening and reading/parsing files from within PHP is relatively
  slow.
* Using md5() to hash strings is pretty fast.
* Database connections and queries are orders of magnitude slower than any of
  the above.
* Calling external programs like convert to manipulate images, etc. is also
  very slow.

This set of facts points out some simple strategies for keeping pages
efficient while still getting a high level of automation:

* Cache results of lengthy operations.
* If a function uses a lot of time to run, yet always produces the same
  output given the same arguments, those arguments can be concatenated
  together into a long string, md5 hashed, and the result can be saved in a
  file whose name is the result of the hash. The next time, the function only
  needs to calculate the hash and check if the file exists.
* If the data cached is prone to update independently, such as from a
  database query, the function can just check the datestamp on the cache file
  and use a suitable timeout to regenerate it. Even regenerating the file
	every 20 seconds will reduce the load on the webserver to almost zero.

With these strategies, there's almost no limit to the level of automation one
can build into templates. You can convert and generate images on the fly, do
heavy database crunching, and generally build in a *lot* of magic, and it's
all going to be very fast.


> (BTW, I experimented with a Hubble shot for a possible Developer
> background:
> http://www.mindspring.com/~digitect/gnome/comp-stevehall-07a.htm. The
> main point is that a dark background needs a different color of
> text--maybe the nav bar link colors should adjust to the theme rather
> than stay one color.)

Possibly, yes. I don't think there are that many images that will require a
different link color, perhaps we can have just one light and one dark, or
some such.

-- 
Joakim Ziegler - Ximian web monkey - joakim ximian com - Radagast IRC
  FIX sysop - free software coder - FIDEL & Conglomerate developer
         http://www.avmaria.com/ - http://www.ximian.com/