chi [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 21, 2001 12:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Adaptive Caching [was Re: initial checkin of the Scheme
> code]
>
>
> Paulo Gaspar wrote:
>
> > Notice that my focus is just cache efficiency. And, unlike wh
Paulo Gaspar wrote:
> Notice that my focus is just cache efficiency. And, unlike what I have been
> able to transmit, I am interested on significant improvements.
Than we share the same concern :)
[skipped a good example of the need for a sampling key for resource
families]
I think I got you i
Hi Judson,
> -Original Message-
> From: Judson Lester [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 19, 2001 10:24 PM
>
> Please forgive me if I'm being a buttinsky, but...
No, you made what I said much clearer. Maybe I wouldn't have written that
long post yesterday if I had see
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 19, 2001 5:39 PM
>
> Paulo Gaspar wrote:
>
> > > So, please, try to see the entire system and not the single page.
> >
> > Of course. I am NOT saying "we must have no errors", I am saying
Please forgive me if I'm being a buttinsky, but...
> > What I do not understand is: having an XML fragment produced by a given
> > generator (that gets an invoice from the database and "translates" it
> > into XML), do you _always_ track costs per each invoice instance comming
> > from that gener
Paulo Gaspar wrote:
> > So, please, try to see the entire system and not the single page.
>
> Of course. I am NOT saying "we must have no errors", I am saying "maybe
> we could have less errors".
Absolutely, if you have ideas on how to do a better sampling than what I
explained, I'll be very ha
Hi Stefano,
Answer inline:
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 17, 2001 12:50 PM
>
> Paulo Gaspar wrote:
>
> > What I mean is that the cache could accumulate quite some wrong cost
> > measurements for long periods of time i
Paulo Gaspar wrote:
> What I mean is that the cache could accumulate quite some wrong cost
> measurements for long periods of time if they would happen with
> resources having a long "cache life".
Correct, but there is no such thing as a perfect cache. Keep this in
mind. We are dealing with stoc
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>
>>However, what I see as more practical is that the specific files cached
>>might change by the time of day. For instance, web administrators usually
>>have log analyzers that will easily determine which parts of the site get
>>hit heaviest
Answer inline:
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 16, 2001 1:15 AM
>
> Paulo Gaspar wrote:
>
> ...
>
> > Otherwise the cache can end up
> > "thinking" that a given document was very expensive just because it
> > happened to
Answer inline:
> -Original Message-
> From: Antti Koivunen [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, December 15, 2001 5:24 PM
>
> ...
>
> > However, as you also mention, there is the cost of sampling. If you
> > have a processing time expensive document "A" with a maximum cache
> >
Antti Koivunen wrote:
> > Everytime a request comes, I have the information on the 'estimated'
> > time the resource will need to be generated on the different routes.
> > Once the decision is taken, I have the information on how much it took
> > to get it and I can compare it with the "assumed"
Paulo Gaspar wrote:
> This is very interesting stuff! And I like very much the hotspot
> analogy. I was also following the initial cache discussion but I
> missed the document you attached.
>
> I am only going to focus on the major obstacle I see:
> - sampling accuracy.
ok
> In most cases (e
Berin Loritsch wrote:
> However, what I see as more practical is that the specific files cached
> might change by the time of day. For instance, web administrators usually
> have log analyzers that will easily determine which parts of the site get
> hit heaviest at which time of day. This is ve
Good points, Paulo. A few short comments...
Paulo Gaspar wrote:
> Hi Stefano and other caching maniacs,
>
>
> I am just going to make a brief post now, since I am overloaded at
> the moment (hence my delay on replying).
>
> This is very interesting stuff! And I like very much the hotspot
Gerhard Froehlich wrote:
>>From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>>
>>
>
>
>
> Berin, you introduced some days ago a Profiler in Avalon Excalibur. Is that
> Component designed to handle such things?
>
> Gerhard (still trying to get the big picture of caching)
It was yesterday
>From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
>
>Everytime a request comes, I have the information on the 'estimated'
>time the resource will need to be generated on the different routes.
>Once the decision is taken, I have the information on how much it took
>to get it and I can compar
Hi Stefano and other caching maniacs,
I am just going to make a brief post now, since I am overloaded at
the moment (hence my delay on replying).
This is very interesting stuff! And I like very much the hotspot
analogy. I was also following the initial cache discussion but I
missed the docum
I didn't yet have time to read your essay on caching (I will), but a few
thoughts...
Stefano Mazzocchi wrote:
>
>
> Everytime a request comes, I have the information on the 'estimated'
> time the resource will need to be generated on the different routes.
> Once the decision is taken, I have
Berin Loritsch wrote:
>
> Berin Loritsch wrote:
>
> > Stefano Mazzocchi wrote:
> >
> >> Talking about placing too many irons in the fire :)
> >>
> >
> >
> > Stefano, please forgive my ignorance, as I have an Associates Degree in
> > Music Recording, and not a traditional CS degree. I haven't ha
Berin,
>-Original Message-
>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, December 13, 2001 4:43 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Adaptive Caching [was Re: initial checkin of the Scheme
>code]
>
>
>Berin Loritsch wrote:
&
was Re: initial checkin of the Scheme
>code]
>
>
>Stefano Mazzocchi wrote:
>
>> Talking about placing too many irons in the fire :)
>>
>
>
>Stefano, please forgive my ignorance, as I have an Associates Degree in
>Music Recording, and not a traditional CS degree
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>Stefano Mazzocchi wrote:
>>
>>I
>>don't know
>>what the letter above the sigma or below the sigma is supposed to signify.
>>
>
> The sigma is like a summing for-loop. Example:
>
>
>>> n
>>> --
>
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Stefano Mazzocchi wrote:
>
> I
> don't know
> what the letter above the sigma or below the sigma is supposed to signify.
The sigma is like a summing for-loop. Example:
> >
> >n
> >--
> > Invalid(r) = \ (V(r,
Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>> Talking about placing too many irons in the fire :)
>>
>
>
> Stefano, please forgive my ignorance, as I have an Associates Degree in
> Music Recording, and not a traditional CS degree. I haven't had the
> higher math classes you and many o
Stefano Mazzocchi wrote:
> Talking about placing too many irons in the fire :)
>
Stefano, please forgive my ignorance, as I have an Associates Degree in
Music Recording, and not a traditional CS degree. I haven't had the
higher math classes you and many others have had here.
I understand Alg
Talking about placing too many irons in the fire :)
Paulo Gaspar wrote:
> The "adaptive caching" idea just arrived too early but I hope it is not
> forgotten.
You can bet your ass it's not :) [excuse my oxford english]
The concept I proposed (more than 6 months ago) about adaptive caching
is d
Extremely interesting exchange of ideas.
Just to add something on the "adaptive caching" issue: it is possibly
the only way to get really efficient caching. I do not think that it is
"probably too difficult to understand", I just think that we do not know
enough and have to crawl before we walk
Jason Foster wrote:
> > The golden rule to avoid FS is: give users all the freedom they need,
> > but no more than that.
> >
> > This is what we did for the sitemap and even it's entirely possible for
> > you to write your sitemap by hand in java, I don't know of anybody who
> > did it.
>
> I wo
>> An (IMHO) equally valid "theory" is that we could also make the
>> semantics
>> pluggable.
>
> I disagree here since looks like FS from all the point I look at it.
You're right, but...
> Well, your statement could easily be extended to say that one
> concept is
> a Turing machine, everyth
Jason Foster wrote:
>
> > Moreover, now that we clearly identified the SoC between
> > syntax/semantics and many examples showed that the same semantics could
> > be equally expressed with different syntaxes, it's good that we now
> > concentrate on the semantics and let the syntax be the last of
> Moreover, now that we clearly identified the SoC between
> syntax/semantics and many examples showed that the same semantics could
> be equally expressed with different syntaxes, it's good that we now
> concentrate on the semantics and let the syntax be the last of our
> concerns.
>
> In theory,
just some over-the-head comments from a community-leadership
perspective:
Ovidiu Predescu wrote:
>
> Hi,
>
> I've just checked in the initial code for the Scheme integration. It
> is in scratchpad/schecoon/ (for lack of a better name) in the main
> trunk.
Let me state this loud and clear: we s
33 matches
Mail list logo
