Subject:
|
Re: Linking between FAQ items (Was: [LDraw FAQ] Who wrote LDraw?)
|
Newsgroups:
|
lugnet.faq
|
Date:
|
Fri, 14 May 1999 20:22:46 GMT
|
Viewed:
|
1544 times
|
| |
|
|
In lugnet.faq, jsproat@geocities.com (Sproaticus) writes:
> Todd Lehman wrote:
> > No, because it's unlikely that the website will contain any files with the
> > .html extension -- they'll definitely all be generated on-the-fly (dunno
> > what the URLs will look like yet) with transparent caching of generated
> > content.
>
> I'm just curious, FMI (1): Why generate them on-the-fly when you only
> really need to generate them once after a change?
Although the number of possible views into the FAQ is finite, it may very
well be an extremely large number when all is said and done -- that is, when
viewing options are taken into consideration. For example, the sitemap.cgi
pages, based at
http://www.lugnet.com/sitemap.cgi
currently encompass 992 different viewing possibilities (one for each group,
plus multiple depth options for higher-level groups).
> What advantage does on-the-fly generation give us?
One advantage is disk space...(not really a big deal if there are only 1000
viewing possibilities -- but extremely important if there are 10^20 viewing
possibilities :-).
On-the-fly generation is a core part of the emerging LUGNET website
architecture/philosophy -- the idea being maximum flexibility and
instantaneous updates across related pages. For example, when a new article
appears in a 75-message thread, it would really suck to have to go modify
all 74 of the other message pages to add the new node into the graphical
thread tree representation. It would be even worse to have to go modify all
~5000 possible views into the expanded sub-trees of every node on the
thread.
Now imagine how much of a hassle it would be if something in the headers of
all the pages in the system needed to change for some reason. It would mean
looping over zillions and zillions of pages and rewriting them just in case
they might be accessed. It's so much easier just to make a change in one
spot and let the server build the pages on the fly.
You can think of it as "just in time" creation of a page -- the final
manifestation of the page never really exists until it is needed.
And what if the final manifestation of every page is slightly different for
each person? Like someone wants banner ads and someone else doesn't? Or
someone has a little flag marker (a to-do item or a bid bump) in their
"you've got stuff" box at the top of the page? That kind of thing can't be
done with static pages.
Down the road, the only pages on lugnet.com that won't be generated on-the-
fly will be legacy pages such as (for example) the Fibblesnork LEGO Guide.
And right now even, 97% of the pages that people see are currently generated
on-the-fly.
> Or when you say transparent caching, that means that the FAQ items are only
> generated once after a change?
It means that they're never generated until someone asks to see them -- just
like what happens now when someone asks to see a news article or thread tree
or a set in the sets-DB.
By "transparent caching" I mean that the server could (if it sees that it
would save significant CPU cycles) choose to cache the final HTML output
pages it creates so that next time they're requested, they can be pulled
from the cache rather than actually regenerating them. (Typically, this
would mean improving the HTTP response time, say, from 1/10 second to 1/100
second on such pages under a heavy load.) And this would be transparent to
the user because the URLs would be identical whether the page is generated
on-the-fly or pulled from the cache.
--Todd
|
|
Message is in Reply To:
24 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
