Problem: to insert the content of a file in an HTML document at a specific location.
One possible way is to add a WebCharm tag like this:
<%@charm:text 20 0 my_include_file.txt %>
When the HTML template is processed by a WebCharm-aware web server, the
content of my_include_file.txt is inserted at the tag location.
This work very much like the SSI #include tag. However, you have more control
on how my_include_file.txt is cached. In the above example, the file is initially cached
and then fetched after the tag is processed 20 times. That is, fetched once per 20 requests.
Tag caching (and template caching) increases page generation speed during server
response.
Visit edgesoft.ca web site for more information on WebCharm template and tags.
In particular, www.edgesoft.ca/go/index.html?top=wc
--
Long On
Edgesoft Consulting Inc.
webcharmer @ www.edgesoft.ca/go/member/index.html www.edgesoft.ca/go/index.html www.edgesoft.ca 22  2861 
In article <lW****************@news01.bloor.is.net.cable.roge rs.com>, one of infinite monkeys
at the keyboard of "Long" <lo***********@rogers.com> wrote: Problem: to insert the content of a file in an HTML document at a specific location.
Long ago solved. Many solutions available.
One possible way is to add a WebCharm tag like this:
<%@charm:text 20 0 my_include_file.txt %>
A solution that breaks as soon as some-processor is not available is a poor
solution. Doubly so when some-processor is a specific implementation
as opposed to an open spec.
This work very much like the SSI #include tag.
Nope. SSI doesn't break HTML (or XML) if the processor is not available.
However, you have more control
on how my_include_file.txt is cached.
You have more *useful* control with XBitHack.
In the above example, the file is initially cached
and then fetched after the tag is processed 20 times.
What a mindbogglingly irrelevant criterion for cacheing!
Tag caching (and template caching) increases page generation speed during server
response.
Erm, yes. True (at least so long as the overhead of your engine is less
than the saving), but by no means new.
Visit edgesoft.ca web
Now that's intriguing. Is the similarity of your name to that of Edge-Side
Includes pure coincidence? Guess I'll have to take a look when I can
get a 'net connection.
--
Nick Kew
In urgent need of paying work - see http://www.webthing.com/~nick/cv.html
"Nick Kew" <ni**@fenris.webthing.com> wrote in message news:ru***********@jarl.webthing.com...
: In article <lW****************@news01.bloor.is.net.cable.roge rs.com>, one of infinite monkeys
: at the keyboard of "Long" <lo***********@rogers.com> wrote:
: > Problem: to insert the content of a file in an HTML document at a specific location.
:
: Long ago solved. Many solutions available.
:
: > One possible way is to add a WebCharm tag like this:
: >
: > <%@charm:text 20 0 my_include_file.txt %>
:
: A solution that breaks as soon as some-processor is not available is a poor
: solution. Doubly so when some-processor is a specific implementation
: as opposed to an open spec.
:
We did not think this was much of a concern, since it should be used WITH
a processor (WebCharm), otherwise there would be no point. However, it is
not difficult to modify the tag to look like:
<!--@charm:text 20 0 my_include_file.txt @-->
We will consider it in the next release.
: > This work very much like the SSI #include tag.
:
: Nope. SSI doesn't break HTML (or XML) if the processor is not available.
:
: > However, you have more control
: > on how my_include_file.txt is cached.
:
: You have more *useful* control with XBitHack.
:
: > In the above example, the file is initially cached
: > and then fetched after the tag is processed 20 times.
:
: What a mindbogglingly irrelevant criterion for cacheing!
:
Consider that the template and tag is cached and you have updated the .txt file
content. How would you un-cache and force reload?
: > Tag caching (and template caching) increases page generation speed during server
: > response.
:
: Erm, yes. True (at least so long as the overhead of your engine is less
: than the saving), but by no means new.
:
: > Visit edgesoft.ca web
:
: Now that's intriguing. Is the similarity of your name to that of Edge-Side
: Includes pure coincidence? Guess I'll have to take a look when I can
: get a 'net connection.
:
Never heard of E-S I. Could you provide a link?
Long
: --
: Nick Kew
:
: In urgent need of paying work - see http://www.webthing.com/~nick/cv.html
"Long" <lo***********@rogers.com> wrote: "Nick Kew" <ni**@fenris.webthing.com> wrote in message news:ru***********@jarl.webthing.com...
: In article <lW****************@news01.bloor.is.net.cable.roge rs.com>, one of infinite monkeys
: at the keyboard of "Long" <lo***********@rogers.com> wrote:
: >
: > In the above example, the file is initially cached
: > and then fetched after the tag is processed 20 times.
:
: What a mindbogglingly irrelevant criterion for cacheing!
:
Consider that the template and tag is cached and you have updated the .txt file
content. How would you un-cache and force reload?
I think you missed Nick's point.
Why 20 times? Why not 19? or 21? Or 20,000?
How do you know in advance how much caching you need? One week you may
only be getting a trickle of visitors between updates, the next week
you're slashdotted.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"Steve Pugh" <st***@pugh.net> wrote in message news:bb********************************@4ax.com...
: "Long" <lo***********@rogers.com> wrote:
: >"Nick Kew" <ni**@fenris.webthing.com> wrote in message news:ru***********@jarl.webthing.com...
: >: In article <lW****************@news01.bloor.is.net.cable.roge rs.com>, one of infinite monkeys
: >: at the keyboard of "Long" <lo***********@rogers.com> wrote:
: >: >
: >: > In the above example, the file is initially cached
: >: > and then fetched after the tag is processed 20 times.
: >:
: >: What a mindbogglingly irrelevant criterion for cacheing!
: >:
: >Consider that the template and tag is cached and you have updated the .txt file
: >content. How would you un-cache and force reload?
:
: I think you missed Nick's point.
: Why 20 times? Why not 19? or 21? Or 20,000?
:
Ah... 20 times is just for the example. The author marking up the tag can specify
an appropriate value for his/her use, base on experience or guestimate.
: How do you know in advance how much caching you need? One week you may
: only be getting a trickle of visitors between updates, the next week
: you're slashdotted.
:
: Steve
:
: --
: "My theories appal you, my heresies outrage you,
: I never answer letters and you don't like my tie." - The Doctor
:
: Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
"Long" <lo***********@rogers.com> wrote: "Steve Pugh" <st***@pugh.net> wrote in message news:bb********************************@4ax.com...
: "Long" <lo***********@rogers.com> wrote:
: >"Nick Kew" <ni**@fenris.webthing.com> wrote in message news:ru***********@jarl.webthing.com...
: >: In article <lW****************@news01.bloor.is.net.cable.roge rs.com>, one of infinite monkeys
: >: at the keyboard of "Long" <lo***********@rogers.com> wrote:
: >: >
: >: > In the above example, the file is initially cached
: >: > and then fetched after the tag is processed 20 times.
: >:
: >: What a mindbogglingly irrelevant criterion for cacheing!
: >:
: >Consider that the template and tag is cached and you have updated the .txt file
: >content. How would you un-cache and force reload?
: I think you missed Nick's point.
: Why 20 times? Why not 19? or 21? Or 20,000?
:
Ah... 20 times is just for the example. The author marking up the tag can specify
an appropriate value for his/her use, base on experience or guestimate.
I know that 20 is just an example, but you are still missing the
point. What does the number of times the document has been accessed
have to do whether it should be cached or not? Why not base the
decision to cache on something more relevant such as the date, or the
freshness of the include file?
The cache we are talking about here is on the web charm enabled web
sevrer, 'cos nothing you put in the include instruction is going to
affect proxy or browser caches, right? So why not include a nice
littel control panel that let's the author flush the cache clear at
his discretion? Or have the server automatically flush the cache when
a new include file is uploaded. Why reduce it to guessing based on how
many times the final page has been accessed?
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
On Wed, 22 Oct 2003, Long wrote: "Steve Pugh" <st***@pugh.net> wrote in message news:bb********************************@4ax.com...
: I think you missed Nick's point.
: Why 20 times? Why not 19? or 21? Or 20,000?
:
Ah... 20 times is just for the example.
Now we _know_ you missed Nick's point.
The author marking up the tag can specify
an appropriate value for his/her use, base on experience or guestimate.
You evidently don't understand yet that it wasn't the specific _value_
that was at issue, but the very idea of basing cacheability on such an
irrelevant quantity, no matter *what* its value.
"Steve Pugh" <st***@pugh.net> wrote in message news:48********************************@4ax.com...
: "Long" <lo***********@rogers.com> wrote:
: >"Steve Pugh" <st***@pugh.net> wrote in message news:bb********************************@4ax.com...
: >: "Long" <lo***********@rogers.com> wrote:
: >: >"Nick Kew" <ni**@fenris.webthing.com> wrote in message news:ru***********@jarl.webthing.com...
: >: >: In article <lW****************@news01.bloor.is.net.cable.roge rs.com>, one of infinite
monkeys
: >: >: at the keyboard of "Long" <lo***********@rogers.com> wrote:
: >: >: >
: >: >: > In the above example, the file is initially cached
: >: >: > and then fetched after the tag is processed 20 times.
: >: >:
: >: >: What a mindbogglingly irrelevant criterion for cacheing!
: >: >:
: >: >Consider that the template and tag is cached and you have updated the .txt file
: >: >content. How would you un-cache and force reload?
: >
: >: I think you missed Nick's point.
: >: Why 20 times? Why not 19? or 21? Or 20,000?
: >:
: >Ah... 20 times is just for the example. The author marking up the tag can specify
: >an appropriate value for his/her use, base on experience or guestimate.
:
: I know that 20 is just an example, but you are still missing the
: point. What does the number of times the document has been accessed
: have to do whether it should be cached or not? Why not base the
: decision to cache on something more relevant such as the date, or the
: freshness of the include file?
:
: The cache we are talking about here is on the web charm enabled web
: sevrer, 'cos nothing you put in the include instruction is going to
: affect proxy or browser caches, right? So why not include a nice
: littel control panel that let's the author flush the cache clear at
: his discretion? Or have the server automatically flush the cache when
: a new include file is uploaded. Why reduce it to guessing based on how
: many times the final page has been accessed?
:
Having the author manually flush the cache is a bad idea. I centainly would
not want to do it. Within an ISP environment how would you control who
flushes what?
In the larger scheme, a WebCharm template can be configure to un-cache
after a period of inactivity (i.e. no page requests). This un-caches all contained
tags so everthing gets flushed automatically. A different scenario happens when
the template is so busy serving requests that it never (may be days) get flushed and
in the mean time you have changed the include content. Having the tag flush
periodically helps keep content up to date, sooner. We could have chosen to do a
time-flush at the tag level, but a count-flush work just as well.
--
Long On
Edgesoft Consulting Inc.
webcharmer @ www.edgesoft.ca/go/member/index.html www.edgesoft.ca/go/index.html www.edgesoft.ca
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk...
: On Wed, 22 Oct 2003, Long wrote:
:
: > "Steve Pugh" <st***@pugh.net> wrote in message
news:bb********************************@4ax.com...
:
: > : I think you missed Nick's point.
: > : Why 20 times? Why not 19? or 21? Or 20,000?
: > :
: > Ah... 20 times is just for the example.
:
: Now we _know_ you missed Nick's point.
:
: > The author marking up the tag can specify
: > an appropriate value for his/her use, base on experience or guestimate.
:
: You evidently don't understand yet that it wasn't the specific _value_
: that was at issue, but the very idea of basing cacheability on such an
: irrelevant quantity, no matter *what* its value.
May be so. Perhaps you will change your mind after reading my reponse
to Steve's post.
--
Long On
Edgesoft Consulting Inc.
webcharmer @ www.edgesoft.ca/go/member/index.html www.edgesoft.ca/go/index.html www.edgesoft.ca
On Wed, 22 Oct 2003, Steve Pugh wrote: What does the number of times the document has been accessed
have to do whether it should be cached or not? Why not base the
decision to cache on something more relevant such as the date, or the
freshness of the include file?
Indeed. Or consult that well recommended tutorial by
Mark Nottingham, http://www.mnot.net/cache_docs/ for a better
understanding of what's afoot.
'cos nothing you put in the include instruction is going to
affect proxy or browser caches, right?
Right...
So why not include a nice littel control panel that let's the author
flush the cache clear at his discretion?
Bit late for that, isn't it? Once a client or their proxy has got
the old version of the document cached, it'll stay cached till they
feel good and ready for a server check. There's nothing that the
author can meaningfully do to pre-empt that (check M.N's tutorial for
the things that the *can* usefully do).
Or have the server automatically flush the cache when
a new include file is uploaded.
Oh, you're talking about a server front-end cache (sometimes called
"httpd accelerator") that's under control of the server operator?
Sure, that's something that's perfectly solvable, in any number of
different ways - but still doesn't address the issue of what actually
happens "out there" on the web.
cheers
In article <SM******************@news01.bloor.is.net.cable.ro gers.com>, one of infinite monkeys
at the keyboard of "Long" <lo***********@rogers.com> wrote: We did not think this was much of a concern, since it should be used WITH
a processor (WebCharm), otherwise there would be no point.
Bzzt. Serverside in-html parsing is such a mid-1990s thing. Nowadays
it's settled down, and the solutions are stable. What do you have
that would induce anyone to abandon PHP or even ASP?
However, it is
not difficult to modify the tag to look like:
<!--@charm:text 20 0 my_include_file.txt @-->
Why am I not in the least surprised? Sounds like a murky tag-soup parser.
Never heard of E-S I. Could you provide a link?
that'd be www.esi.org and others. The backers and authorship of
ESI, and the published spec, seem to add credibility. BTW, there's
an implementation of ESI available for Apache.
--
Nick Kew
In urgent need of paying work - see http://www.webthing.com/~nick/cv.html
"Nick Kew" <ni**@fenris.webthing.com> wrote in message news:0a***********@jarl.webthing.com...
: In article <SM******************@news01.bloor.is.net.cable.ro gers.com>, one of infinite monkeys
: at the keyboard of "Long" <lo***********@rogers.com> wrote:
: > We did not think this was much of a concern, since it should be used WITH
: > a processor (WebCharm), otherwise there would be no point.
:
: Bzzt. Serverside in-html parsing is such a mid-1990s thing. Nowadays
: it's settled down, and the solutions are stable. What do you have
: that would induce anyone to abandon PHP or even ASP?
:
The two posts that I originate so far only have scratched at the surface
of WebCharm features. My next post will introduce a more powerful
tag for your review.
: > However, it is
: > not difficult to modify the tag to look like:
: >
: > <!--@charm:text 20 0 my_include_file.txt @-->
:
: Why am I not in the least surprised? Sounds like a murky tag-soup parser.
:
It may be crude, but it works.
: > Never heard of E-S I. Could you provide a link?
:
: that'd be www.esi.org and others. The backers and authorship of
: ESI, and the published spec, seem to add credibility. BTW, there's
: an implementation of ESI available for Apache.
:
Interesting reading. At quick glance, ESI technology seems complicated.
What is the learning curve in using it? Does it require a rocket scientist
to understand how to use it fully?
A primary goal of @charm tags is simplicity so that anyone with an
interest in HTML may use it without much difficulties.
Long
On Wed, 22 Oct 2003 16:06:46 +0000, Long wrote: : >: >: "Long" <lo***********@rogers.com> wrote: : >: >: > In the above
example, the file is initially cached : >: >: > and then fetched after
the tag is processed 20 times.
<snip missing-the-point> In the larger scheme, a WebCharm template can be configure to un-cache
after a period of inactivity (i.e. no page requests). This un-caches all
contained tags so everthing gets flushed automatically. A different
scenario happens when the template is so busy serving requests that it
never (may be days) get flushed and in the mean time you have changed
the include content. Having the tag flush periodically helps keep
content up to date, sooner. We could have chosen to do a time-flush at
the tag level, but a count-flush work just as well.
Er... no it doesn't. What if the page is flushed, then viewed once, then I
change the content. The next _19_ (for example) visitors get an out of
date page!
Likewise with time: All visitors in the next (e.g.) 5 minutes get the
outdated page!
Why not check the modification date of the included file, see if it's
changed, and then decide if the cached page is current? That way, zero
visitors get the outdated page! :-)
HTH :-) HAND
--
Matt
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
In article <pa****************************@hotmail.com>, one of infinite monkeys
at the keyboard of Matt <ma**********@hotmail.com> wrote: Why not check the modification date of the included file, see if it's
changed, and then decide if the cached page is current? That way, zero
visitors get the outdated page! :-)
Erm, far too sensible.
Besides, that's what the rest of the world[1] has been doing for years,
so he'd lose his selling point.
[1] well, those with a clue
--
Nick Kew
In urgent need of paying work - see http://www.webthing.com/~nick/cv.html
"Matt" <ma**********@hotmail.com> wrote in message
news:pa****************************@hotmail.com...
: On Wed, 22 Oct 2003 16:06:46 +0000, Long wrote:
:
: > : >: >: "Long" <lo***********@rogers.com> wrote: : >: >: > In the above
: > example, the file is initially cached : >: >: > and then fetched after
: > the tag is processed 20 times.
: <snip missing-the-point>
: > In the larger scheme, a WebCharm template can be configure to un-cache
: > after a period of inactivity (i.e. no page requests). This un-caches all
: > contained tags so everthing gets flushed automatically. A different
: > scenario happens when the template is so busy serving requests that it
: > never (may be days) get flushed and in the mean time you have changed
: > the include content. Having the tag flush periodically helps keep
: > content up to date, sooner. We could have chosen to do a time-flush at
: > the tag level, but a count-flush work just as well.
:
: Er... no it doesn't. What if the page is flushed, then viewed once, then I
: change the content. The next _19_ (for example) visitors get an out of
: date page!
:
: Likewise with time: All visitors in the next (e.g.) 5 minutes get the
: outdated page!
:
Sure, what you've described are worse case scenarios. I did said "keep
content up to date, sooner", not at once. Besides, we are not talking about time
sensitive content here, but just in general. If you really want to avoid
tag-cache altogether, just set the value to 1.
: Why not check the modification date of the included file, see if it's
: changed, and then decide if the cached page is current? That way, zero
: visitors get the outdated page! :-)
:
How is this diffent than refresh on every request? You'd still need to access the
file system at each request, to check for the modification date. If the size
of the include file is not huge, the performance gain would be minimal to none.
Long
"Nick Kew" <ni**@fenris.webthing.com> wrote in message news:4s***********@jarl.webthing.com...
: In article <pa****************************@hotmail.com>, one of infinite monkeys
: at the keyboard of Matt <ma**********@hotmail.com> wrote:
:
: > Why not check the modification date of the included file, see if it's
: > changed, and then decide if the cached page is current? That way, zero
: > visitors get the outdated page! :-)
:
: Erm, far too sensible.
:
: Besides, that's what the rest of the world[1] has been doing for years,
: so he'd lose his selling point.
:
: [1] well, those with a clue
:
I wondered why dynamic content generation has been so far dog slow???
"Long" <lo***********@rogers.com> writes: "Matt" <ma**********@hotmail.com> wrote in message
news:pa****************************@hotmail.com...
: Why not check the modification date of the included file, see if it's
: changed, and then decide if the cached page is current? That way, zero
: visitors get the outdated page! :-)
:
How is this diffent than refresh on every request? You'd still need to
access the file system at each request, to check for the modification
date. If the size of the include file is not huge, the performance
gain would be minimal to none.
I think most filesystems do a certain amount of in-memory caching for
file mod times. I don't think most filesystems do in-memory caching of
file contents.
The Apache version of your product is hitting the filesystem for most
requests anyway, to launch the CGI program.
"Bruce Lewis" <br*****@yahoo.com> wrote in message news:nm*************@magic-pi-ball.mit.edu...
: "Long" <lo***********@rogers.com> writes:
:
: > "Matt" <ma**********@hotmail.com> wrote in message
: > news:pa****************************@hotmail.com...
: > : Why not check the modification date of the included file, see if it's
: > : changed, and then decide if the cached page is current? That way, zero
: > : visitors get the outdated page! :-)
: > :
: > How is this diffent than refresh on every request? You'd still need to
: > access the file system at each request, to check for the modification
: > date. If the size of the include file is not huge, the performance
: > gain would be minimal to none.
:
: I think most filesystems do a certain amount of in-memory caching for
: file mod times.
:
Perhaps.
: I don't think most filesystems do in-memory caching of
: file contents.
:
WebCharm allows in-memory caching of templates and include files to
help reduce file I/O, but by no means 100%. This does depend on how a
template and containing tags are configured.
: The Apache version of your product is hitting the filesystem for most
: requests anyway, to launch the CGI program.
:
Yes, this is an inherent behavior of CGI and it is out of our control. Although,
the CGI module (abtwsac) is only 30K in size so the overhead is not too bad.
WebCharm on the other hand is a separate application that stays resident
in memory, once launched.
Long
"Long" <lo***********@rogers.com> writes: "Bruce Lewis" <br*****@yahoo.com> wrote in message news:nm*************@magic-pi-ball.mit.edu...
: "Long" <lo***********@rogers.com> writes:
:
: > "Matt" <ma**********@hotmail.com> wrote in message
: > news:pa****************************@hotmail.com...
: > : Why not check the modification date of the included file, see if it's
: > : changed, and then decide if the cached page is current? That way, zero
: > : visitors get the outdated page! :-)
: > :
: > How is this diffent than refresh on every request? You'd still need to
: > access the file system at each request, to check for the modification
: > date. If the size of the include file is not huge, the performance
: > gain would be minimal to none.
:
: I think most filesystems do a certain amount of in-memory caching for
: file mod times.
:
Perhaps.
Do a google search for "inode cache". One of your supported platforms
(Linux) does exactly this. I doubt it's different from other Unix
implementations. You can configure the size of your inode cache
according to your server's needs.
: I don't think most filesystems do in-memory caching of
: file contents.
:
WebCharm allows in-memory caching of templates and include files to
help reduce file I/O, but by no means 100%. This does depend on how a
template and containing tags are configured.
Your question was "How is this different than refresh on every request?"
I answered that. Matt's suggestion reduces file I/O better than
WebCharm does. For example, if you're using BRL and do
[(paste "my_include_file.txt")]
You'll get better I/O performance (and probably better overall
performance) than with WebCharm's alternative:
<%@charmcnf: pageRequestServlet , 1, *, 2, 60 %>
<%@charm:text 20 0 my_include_file.txt %>
I notice you left that first line out from your initial helpful post.
Your authoring guide says it's required.
: The Apache version of your product is hitting the filesystem for most
: requests anyway, to launch the CGI program.
:
Yes, this is an inherent behavior of CGI and it is out of our
control. Although, the CGI module (abtwsac) is only 30K in size so the
overhead is not too bad. WebCharm on the other hand is a separate
application that stays resident in memory, once launched.
So don't use CGI. BRL doesn't. PHP doesn't. SSI doesn't. You're
behind the pack. And the alternatives I mentioned are all free.
"Bruce Lewis" <br*****@yahoo.com> wrote in message news:nm*************@magic-pi-ball.mit.edu...
: "Long" <lo***********@rogers.com> writes:
:
: > "Bruce Lewis" <br*****@yahoo.com> wrote in message news:nm*************@magic-pi-ball.mit.edu...
: > : "Long" <lo***********@rogers.com> writes:
: > :
: > : > "Matt" <ma**********@hotmail.com> wrote in message
: > : > news:pa****************************@hotmail.com...
: > : > : Why not check the modification date of the included file, see if it's
: > : > : changed, and then decide if the cached page is current? That way, zero
: > : > : visitors get the outdated page! :-)
: > : > :
: > : > How is this diffent than refresh on every request? You'd still need to
: > : > access the file system at each request, to check for the modification
: > : > date. If the size of the include file is not huge, the performance
: > : > gain would be minimal to none.
: > :
: > : I think most filesystems do a certain amount of in-memory caching for
: > : file mod times.
: > :
: > Perhaps.
:
: Do a google search for "inode cache". One of your supported platforms
: (Linux) does exactly this. I doubt it's different from other Unix
: implementations. You can configure the size of your inode cache
: according to your server's needs.
:
Thanks for the pointer. Very helpful.
: > : I don't think most filesystems do in-memory caching of
: > : file contents.
: > :
: > WebCharm allows in-memory caching of templates and include files to
: > help reduce file I/O, but by no means 100%. This does depend on how a
: > template and containing tags are configured.
:
: Your question was "How is this different than refresh on every request?"
: I answered that. Matt's suggestion reduces file I/O better than
: WebCharm does.
:
Now that I know about "inode cache". In the next release, we will consider
checking for file mod timestamp, to refresh the cached content. It probably will
simplify the tag syntax as well. Thank you both.
: For example, if you're using BRL and do
:
: [(paste "my_include_file.txt")]
:
BRL? Never heard of it...until now. I had a quick look and it is very interesting.
BRL seems to be equivalent to WebCharm/e (enterprise edition) in terms
of functionality. One difference is in BRL's own programming language, instead
of Scheme. Whereas, WebCharm is base solely on templates and tags and
new functions in WebCharm/e are programed in Smalltalk.
: You'll get better I/O performance (and probably better overall
: performance) than with WebCharm's alternative:
:
: <%@charmcnf: pageRequestServlet , 1, *, 2, 60 %>
: <%@charm:text 20 0 my_include_file.txt %>
:
I do appreciate that you actually spend some time to evaluate WebCharm.
: I notice you left that first line out from your initial helpful post.
: Your authoring guide says it's required.
:
This is correct, I wanted to only concentrate on the #include equivalent tag. But
in practice, a WebCharm template is identified by the inclusion of a @charmcnf
signature.
: > : The Apache version of your product is hitting the filesystem for most
: > : requests anyway, to launch the CGI program.
: > :
: > Yes, this is an inherent behavior of CGI and it is out of our
: > control. Although, the CGI module (abtwsac) is only 30K in size so the
: > overhead is not too bad. WebCharm on the other hand is a separate
: > application that stays resident in memory, once launched.
:
: So don't use CGI. BRL doesn't. PHP doesn't. SSI doesn't. You're
: behind the pack. And the alternatives I mentioned are all free.
:
We do have access to a CGI alternative that is Java-based and runs within
a Java container (such as Tomcat). Performance wise, it is much better than
CGI. However it is a can of worm to install and configure. We wanted to keep
WebCharm easy to install and use as a trade-off, so we excluded the option.
Regards,
Long
On Wed, 22 Oct 2003 16:06:46 +0000, Long wrote: : >: >: "Long" <lo***********@rogers.com> wrote:
: >: >: > In the above example, the file is initially cached
: >: >: > and then fetched after the tag is processed 20 times.
<snip missing-the-point> In the larger scheme, a WebCharm template can be configure to un-cache
after a period of inactivity (i.e. no page requests). This un-caches all contained
tags so everthing gets flushed automatically. A different scenario happens when
the template is so busy serving requests that it never (may be days) get flushed and
in the mean time you have changed the include content. Having the tag flush
periodically helps keep content up to date, sooner. We could have chosen to do a
time-flush at the tag level, but a count-flush work just as well.
Er... no it doesn't. What if the page is flushed, then viewed once, then I
change the content. The next _19_ (for example) visitors get an out of
date page!
Likewise with time: All visitors in the next (e.g.) 5 minutes get the
outdated page!
Why not check the modification date of the included file, see if it's
changed, and then decide if the cached page is current? That way, zero
visitors get the outdated page! :-)
HTH :-) HAND
--
Matt
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Matt wrote: Why not check the modification date of the included file, see if it's
changed, and then decide if the cached page is current? That way, zero
visitors get the outdated page! :-)
That's only really possible iff all your included content has
timestamps. If you start generating pages from database content (most
of the time; there are some CMS schema that actually have useful time
information) or output from a program, then you're pretty much stuck
assuming that the data will be fresh for a specific period of time. In
some cases with databases, the overhead of checking the timestamp is
high enough that you may as well either not bother or pull the whole
page anyways, at which point you lose the benefit of caching.
Granted, the OP isn't doing that, s/he's including a .txt file, but
it's something to think about.
Owen This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Kupo |
last post by:
Hi, I'm currently writing website using php. My problem is, when I do:
include("../../library/file.php"); // this is from e.g
/level1/level2/something.php
it works. However, when I use:
...
|
by: Greg |
last post by:
I'm new to html and web coding, this is a simple one -
appreciate your help!
I'm attempting to get my browser bar links to reside in a
single .asp file to avoid multiple additions to pages
when...
|
by: .:mmac:. |
last post by:
I have to update a page every week. I get the page ahead of time so I used
the "scheduled includes" webbot in Frontpage only to find that I would have
to refresh the page every week to have it...
|
by: Adam |
last post by:
Hi All,
Is it possible to use includes dynamically in html.
Hopefully the following example will give an idea what I am rying to do.
Thanks in advance
Adam
<script language="javascript">
|
by: tshad |
last post by:
In my User control, I tried to do this:
***************************************************************************
<Script runat="server">
Public ClientName As String = "<!-- #include file =...
|
by: MBS |
last post by:
I am playing around with some PHP code. I want to put in an include()
function so I can include existing HTML code and output it to the browser.
Lo and behold PHP does not support relative paths...
|
by: cybervigilante |
last post by:
I can't seem to change the include path on my local winmachine no
matter what I do. It comes up as
includ_path .;C:\php5\pear in phpinfo() but there is no such file. I
installed the WAMP package...
|
by: Jon Slaughter |
last post by:
I'm using eval to excute some mixed php and html code but I cannot debug it.
I am essentially using filegetcontents to load up a php/html file and then
inserting it into another php/html file and...
|
by: Michael |
last post by:
Since the include function is called from within a PHP script, why
does the included file have to identify itself as a PHP again by
enclosing its code in <?php... <?>
One would assume that the...
|
by: j.woodcock |
last post by:
is there a way of having a file that's name is a variable (eg
dependant on the user name) act like a include.
i know that you cant define the file for an include asp tag using a
variable and that...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
