W3C home > Mailing lists > Public > www-jigsaw@w3.org > September to October 1999

Re: concerning frames

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 25 Oct 1999 22:43:01 +0200 (MET DST)
To: Remo Strotkamp <remo@ccrl.nj.nec.com>
cc: W3 Jigsaw Mailinglist <www-jigsaw@w3.org>
Message-ID: <Pine.GSO.4.20.9910252212140.16871-100000@tarantula.inria.fr>
On Sun, 24 Oct 1999, Remo Strotkamp wrote:

> Hi there,
> I have another question:
> I don't really understand the hole frame thing.
> The document "Jigsaw: An object oriented server" which explains the
> evolvement of the design during 1.x is probably the one that teached
> me most about how jigsaw is working and why things are as they are!
> Unfortunaltely the successor document "internal design of jigsaw 2.0"
> does not stand up to the clarity of the first document.

The "internal design" is a short description of the internals on Jigsaw,
it is placed under "Programmer Doc", for a reason :)

> As a result I don't get the reason behind the separation into resources
> and associated frames. Would be very nice if somebody could explain
> me why it was changed this way and what is the purpose of this
> separation.

The separation between frames and resource allows you to export the same
resource using different protocol, like HTTP, FTP and some others. The
same resource store manager will be used for different servers.

> As all of the frames are named "frame-0" I looks like this is a
> variable local to that specific resource object. So is it possible to
> have different resources linked to the same frame???

This is a local name related to the resource itself.
> The idea behind this question is to a) bether understand it and b) for a
> situation like the following:
> If I have lets say 100 gif pictures representing lets assume throughput
> graphs of 100 different links during a period of one week. The lifetime
> of all of them would be 1 week, until the new graphs are ready.
> So having each of the resources linked to the same frame would be a lot
> more straight forward, clear and also less resource consumptioning!

It would but each HTTPFrame contains some HTTP-related information about
the  underneath resource, like the ETag, cache information (setting the
expire time IS important) and some others. So it would be difficult to
link it to many resources.
Another idea would be to aggregate of override frames during the lookup,
but it would be less intuitive! 
About memory consumption, there are only a limited number of
"stores" (read container resources and their sons) in memory and the LRU
ones are dumped to disk (in XML for 2.1.0 and up)
Hope this explains (some) things,

      /\          - Yves Lafon - World Wide Web Consortium - 
  /\ /  \        Architecture Domain - Jigsaw Activity Leader
 /  \    \/\    
/    \   /  \   http://www.w3.org/People/Lafon - ylafon@w3.org    
Received on Monday, 25 October 1999 16:43:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:35 UTC