Re: API Review Notes 3/6/01

[Rick Potts]

a nsIRequest is just that - an abstract request.  It could be network related, or it could be computation related.  The 'name' associated with a request is meant to be a readable identifier (that could end up in a list of active requests for example)

In the case of a network request (ie. an nsIChannel) there is *also* a URI.  But in the case of layout requests (ie. layout computation) there is not.

If you want to promote URI up to request and say that every request *must* have a URI.  I guess that's fine.  But to me doing so sounds much more like brendan's 'universal hammer' :-)

What's wrong with having a name identifier?  It seems simpler than creating wacky protocols for all of our computations!

On the other hand, maybe we should turn layout into a protocol - then we could invoke reflows via the 'layout-reflow://' protocol :-)

-- rick
 
 

Brendan Eich wrote:

Doug Turner wrote:

[EMAIL PROTECTED]">

Is there some reason that the "name" attribute on nsIRequest is only
sometimes a URI?  I guess what I'm not understanding is why it's
necessary to have channel objects supply both a name attribute and a
URI attribute.  Why not just have every nsIRequest::name be a URI and
do away with the URI attribute on the channel?

Well not all nsIRequest have a URI.  There are dns request that do not have
any concept of a URI.  There are also layout request that do not have a URI to
provide.  The nsIRequest is for something that is suspend-able, resume-able,
and cancel-able.  This does not always have to be something that is network
related, but commonly is.

Does this help?

Cliche time: what's in a name?  when all you have is a hammer, everything looks like a nail!

One counter-point is that we could have URIs for DNS requests, and probably should.  I'd love to use Mozilla rather than nslookup or dig (jwz's Unity of Interface piece comes to mind).

Maybe we should abstract further, from URI to something even more opaque, but still name-like (math-time: equivalence relation defined so you can distinguish between different URIs and partition URIs into equivalence classes).  Or maybe the proposed name attribute is better.   But I would think longer and harder before adding yet another kind of identifier (the I in URI, right?).

Tell us more about those layout cases that do not have a URI.

/be

[EMAIL PROTECTED]">