> But, then,  why doesn't it, also, make sense to use static html pages
> (processed and cached by the web server) and avoid CF & SQL altogether.

I agree. The best, fastest, and most scaleable way to push pages is to push
pre-generated "static" pages as much as possible. I personally would love to
cache everything in the database and have a dedicated server which pumps out
new versions every 30 minutes or so.  But a lot of the sites now a days are
so dynamic it's not possible to skip the cf or sql all together. What I like
to do is cache the slowest and not frequently modified part of a site to the
database and update the content every 30 minutes.

> This may change in the future as we may want to programatically manipulate
> non=text content before presentation.
> If there is a need to maintain a large repository of digital (non-text)
> content then a database appears to offer some significant advantages for:
> accessing, cataloging, security, referential integrity, backup...
> As the web evolves, we may need to change the way we think about non-text
> content...

In a couple of years I bet almost everything and anything will be dynamic.
With XML climbing the ladder as of late I could see a reduction of binary
files. I could see the entire web site delivered as XML text in compressed
form and everything including the images will be described in a format
similar to SVG. Even now, with SVG, we can use any application server to
pump out vector graphics with the vistor's name customized below the site
logo. 

On the subject of text, I believe all major browsers has an internal gzip
decompressor with can deflate the compressed html stream from a web server.
Which webservers compresses the outgoing streams? Is there an option in IIS
that we can set or is this automatic? I'm just curious and would love to
save some bandwith.

> 
> ... what, with applets, embeds, images,etc - what percentage of the typical
> page (at the browser client) is actually text?
> 
> Apple's new OSX uses Quartz for presentation services... this mean that
> everything you see on the screen is in PDF format. (See below).
> 
> Does this mean that we could serve PDF pages directly to a Mac Client and
> eliminate all plug-ins browser overhead, extra OS Presentation  overhead...
> probably!
> 
> Couldn't the same approach apply to images, audio, video... probably!

Didn't Apple go with the PDF approach because the PostScript licensing was
too mcuh? There was this big discussion at the mac site a while back
regarding this. Supposedly PDF can't handle remote imaging but PostScript
can. It's been a while so I can be totally wrong in this. I would have
bought OS X beta if it had support for Airport. But yeah, that would be a
dream of every web developer: having total and constant control of the
client/server connection/interaction. Now you have got me dreaming. =) In a
few years. 

Xing

------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.

Reply via email to