Re: distinguishing browser types

On Mon, 24 Apr 1995, lilley wrote:
> Brian Behlendorf wrote:
> > It's not entirely clear whether Accept: should be used just for inline
> > objects or for all possible objects that can be sent to external
> > applications.  
> 
> The spec you quote seems amply clear on that point. It is talking about 
> requests in general, not just inline image requests. It is also clear that
> the spec says that the Accept header depends on the context of the request 
> (so requests for inline images could and should send different Accept headers 
> from requests for other links). Netscape does not do this.

Alright, I'll concede that - in fact that makes the inline vs. external 
app question have a very nice answer.  Cool.

> > - and now that they're doing tables we wish they'd send text/html;
> > version=3.0 
> 
> Why? 

Because I'd rather dish valid HTML3 to browsers that at least make a stab 
at trying to understand it rather than lie and label a page with tables as 
HTML2 and have perfectly legal HTML2 browsers barf.  But I guess that's 
academic.

> > Other browsers are much worse with their Accept: headers,
> > yes, even Arena (c'mon, guys, why the application/x-island-paint,
> > application/x-island-draw, and application/x-island-write??).
> 
> What is wrong with that? 

I have no way of displaying those data types!  Those weren't listed in my
.mailcap, nor in the system-wide mailcap, and I don't have those
applications on my system. 

> I would suggest a modification of this:
> 
> 2) The browser should scan the system, personal, and any other specified
> mailcap files, noting their modification dates.  It should check thet
> the specified applications exist and bring to the users attention if any
> are missing.  It should then construct it's own mailcap which it can
> rely on.
> 
> 3) The quality factor for each listed type should be user-editable via
> some sort of dialog box or whatever.  The browser shouls also note for
> each type whether it can display that type inline, either natively or
> with a co-operating application.  It should be possible to check for
> updates to the user, system and other specified mailcap files, either on
> startup, or with an update button (ie on user command), as the user
> prefers.

Okay, good rewrite.  

> > 4) Enable use of the "mxb" setting, so that people can determine the
> > maximum amount of information they're willing to accept for a given type 
> > of object, and the provider can scale what they provide accordingly. 
> 
> This looks to be of limited use.  People rarely have a maximum size of
> object (unles it is, like, 10Gbytes or something).  Rather, they have a
> maximum wait, which depends on the size, the network throughput and how
> badly they want to see the object. The browser could conceivably handle 
> the first two parameters.
>
> > No 
> > more "click here for a lower resolution version of the home page"!  The 
> > user can say "I really would prefer 50K or less for each HTML access", 
> 
> I sympathise with your intention, but the max size is not the whole
> story.  Even if it took a max time instead of a max bytes parameter, the
> throughput leaps up and down even within a single connection to a single
> site.  Trying to compute how long it *will* take is problematic.  All
> the browser could really do is offer to automatically terminate inline
> image downloads that have taken too long.
> 
> Even then, some objects I will want to see badly, so will happily wait
> for.  Others I will get bored waiting for very rapidly (perhaps after
> seeing the first one).

Hmm... to some level this seems a user-interface question as much as a 
technical one.  You're right in that I may want to be able to change that 
mxb factor quickly to compensate for slower links or objects I really 
want to see.  What if instead of mxb we used a global q factor of some 
sorts, which the browser implemented as a slider in the menu bar.  The 
definitions of how q values mapped to sizes would be up to the content 
provider... which is fine, as sites that insist on sending me 500K gifs 
when my slider is at .1 will just disappear from my hotlist.

HTTP-NG could enable users to change this q factor on the fly - combine 
that with MPEG compression boards and.....

> What I am saying is, we are some way off being able to remove the "omit
> inline images" button.  And inline images is just one part of the story.
> I do want to be able to tell the server that I can cope with pdb, cgm
> and msdl files.

The resolution of which type to send should only be based on per-type q 
factors, not mxb, it would seem to me.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Monday, 24 April 1995 14:28:05 UTC