Guilty as charged :-)
>Anyway, my basic point is that I
>have no problem with the concept of caching. Where I disagree is to *where*
>functionality for caching should be enabled. To me, caching functionality is
>the responsibility of clients or servers and not objects. Objects should be
>dumb.
I'm not sure we are disagreeing, caching is definately the responsibility
of the client or the server, which is precisely why I call it a "hint",
typically the concept of hint is where something tries to give a clue as to
how to handle it, in other words its something that a smart client can
exploit. Typically in caching schemes (and I think I built the biggest one
on the net - AOL's 18Gbyte Gopher cache!) the problem is what to cache and
for how long, a "hint" explicitly does NOT say use the cache to find the
object, it says to the client that having fetched the object it would
sensible to KEEP a copy in the cache because the server (or the object)
knows that the client is probably going to want it again soon. This should
ONLY effect the speed, absolutely no change in what gets displayed to the
user.
>If you really want defaults, I would try to come
>up with something that would give you the functionality of defaults without
>restricting is utility to defaults. One example of this would be "named
>objects". If a facility for named objects where added to the specification,
>one could use it for defaults as well as many other things such as user
>defined objects or caching without directly addressing those issues.
I guess I'm saying that the URL is (in the abscence of URNs) the name of
the object. Much better than arbritray names like "teapot" because they
also say how to get the generic object if I dont have it cached, or on my
CDROM etc.
>When I'm designing a language or framework and there is a need for a
>new feature, I always ask myself, "can I make this feature possible by
>adding general functionality? Or do I have to add code to specifically add
>this feature." Almost always, I can come up with a general soloution that
>while it does not address the feature directly, adds functionality that
>enables the feature.
I agree, and look forward to suggestions!
In your suggestion, I think the disagreement is not in generic, versus
specific functionality, its in where the control goes, I believe that the
world builder is the one who should control what gets seen, so as an object
builder I put together a kitchen and say that I'd like this really cool
teapot, but in its abscence I'm willing to put up with the generic teapot
that is specified here, I'm typicalyl not going to want to allow just any
old thing that someone else has called a teapot, and if I was a competent
world-builder then I'd test my world with both the specific and generic
components.
- Mitra
=======================================================================
Mitra [email protected]
Internet Consulting (415)826-2499
<http://earth.path.net/mitra> fax (415)826-4423