[X3D-Public] Web3D.org Front Page

[Braden McDaniel]

[Sorry for the delayed response to this.  It was a busy week and
"respond to long e-mail" kept getting put off.]

On Wed, 2009-06-24 at 22:12 -0700, Joe D Williams wrote: 
> >> >>>  <object data="your.wrl" ... >
> >> >>> <param name="src" value="your.wrl" >
> >> >>> </object>
> >> >>>
> >> >>
> >> >> The duplication of data="your.wrl"
> >> >> and
> >> >> name="your.wrl"
> >> >> is just due to the fact that BS didn't recognize the src param.
> >> >
> >> > Presumably you mean "that BS didn't recognize the data 
> >> > attribute".
> >>
> >> No, @data is standard and everybody accepts that.
> 
> Well it is not like the plugin has to accept or use @data. It is a 
> choice.

Supporting Web standards is always a choice.

> > "data" *is* standard; but what Lauren has described suggests that it 
> > doesn't work with Contact.  I don't have Contact here, so I can't 
> > test it myself.  But if this is accurate, I can't say I find it 
> > *that* shocking.  If one were to bolt an NPAPI interface onto an 
> > ActiveX control, it is the sort of thing that could get overlooked 
> > (because it is a way in which ActiveX containers differ in behavior 
> > from NPAPI hosts).
> 
> I believe it. I saw where IE9 will do something different with 
> ActiveX?

I don't know anything about this.

> >> The <param> src, or whatever the X3D browsers makers decide, is the 
> >> one missing last time I checked..In fact, the last time I looked, 
> >> Flux was the only one that accepted the url via a <param>.
> 
> > Flux does so mostly because it is primarily an ActiveX control.  I 
> > think Contact and Cortona are in the same boat there.
> 
> Well, I think in practice it is just tthe way that it works. 
> Regardless, the <object> has some attributes and some custom params. 
> In order to use the custom params the plugin must agree. The best way 
> is when the plugin gets running, then the appropriate attriburte 
> values and the custom parameters are passed to the plugin.
> 
> > IIRC, the ActiveX container has some special awareness of the "src" 
> > param and it gets some special handling.
> 
> Maybe so. That would make it easier as in <embed> but it can be 
> anything, like movie or whatever.  But it is not automatic, maybe it 
> should be another name, and the plugin must set it up. The DOM will 
> follow and create the requested interfaces but won't bother checking 
> if the <param>s in the user code match up.

Okay, now I remember. Let me tell you a story...

In older versions of Internet Explorer (around version 4, IIRC), if you
loaded plug-in content in "full page" mode (e.g.,
"http://example.com/your.wrl" in the Web browser's location bar) and did
"View source", you'd see the source to a brief HTML page with an
"object" element in it.  What the browser was actually doing here was
generating an HTML page for it to render where the page had an "object"
element with its width and height both set to 100%, thus consuming the
entire page area.

Now, Microsoft was an early adopter of the "object" element,
implementing it before it was fully specified.  And it seems that at
some point in "object"'s evolution, the attribute we now know as "data"
was called "src".  Or, at least, that's what the Microsoft developers
who wrote the code to generate this page thought, because the object
element in the page refers to the content handled by the plug-in with an
*attribute* of "object" named "src".

At least in those older versions of IE, this "src" attribute got passed
along to the ActiveX control looking no different from a "src" *param*.
(I would not be surprised if recent versions of IE do not permit "src"
as an attribute.) The upshot of this behavior is that if an ActiveX
control developer wanted his control to be usable in full page mode, the
control *had* to support a "src" param--because that's what the browser
would send in that case.

While I think modern versions of IE have managed to obscure this
generated HTML page from view, I'm pretty sure it's still doing the same
thing behind the curtains. 

[snip]

> >> http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt
> >>
> >> is in work now, but they are mostly skipping the hard parts.
> 
> I meant that is fine but I think it is mising how to sniff multiple 
> media.

I don't think I'm familiar with what you're referring to here.

> > If one simply configures the Web server to send the correct media 
> > type, what's described in that draft is rendered moot.
> 
> True, although the content type header should be damaged and that 
> procedure serves as a recovery. It is real life for W3C browsers. That 
> procedure really does not cover many types of embedded content, but 
> that is OK by me.

Damaged? If your HTTP headers are getting garbled, you have bigger
problems than can be solved with MIME type sniffing.

That draft looks like an attempt to normalize what Web browsers have
been doing for years rather than do anything new.  And that's fine.  But
I don't see how it relates to this discussion. 

> > And note that, should this draft proceed to RFC status, it 
> > wouldpresumably need to update RFC2616 (HTTP/1.1).
> 
> Well, if not updated, the difference is noted.

"Update" is the RFC parlance.

> The important point is that so far, the @data attribute is sort of 
> special.

It's no different from the "src" attribute of "img".  In fact, there's
no reason for a browser to treat "<object data='some-png'></object>" and
"<img src='some-png'>" any differently. 

> >> True, if the media type is not supported the host won't even try. 
> >> There are other problems is the server doesn't provide a matching 
> >> content type.
> 
> >> > I haven't tested it yet, but recent bugzilla.mozilla.org activity 
> >> > leads me to suspect that Firefox 3.5 might finally be 
> >> > implementing this more-or-less to spec.
> 
> >>
> >> Yes, hard to tell what the spec is because they are sort of 
> >> honoring classid.
> >>
> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-0.html#the-object-element
> >>
> 
> >> >> In particular, the browser may try to 'sniff' content type or 
> >> >> other aspects of the file, as well as download the complete file 
> >> >> before sending it to the plugin when data is used. Aside from 
> >> >> the "classid" attribute, *the server-provided media type is the 
> >> >> only specified means to indicate what plug-in should be 
> >> >> started*. That means that a correct implementation cannot start 
> >> >> the plug-in until *after* the resource specified in "data" has 
> >> >> started downloading.
> 
> >>
> >> Fortunately that is not true.
> >
> > It is true as far has HTML 4 is concerned.
> 
> In practice it does not happen that way all the time. Essentiallly the 
> minimum  <object> to get a plugin going is:
> <object type='modelx3d+xml'>
> </object>
> 
> The registered plugin should start up, report in, and accept any 
> attributes and <param>s.

That does reflect the behavior I'm observing in Firefox 3.5.  I don't
think this has been specified anywhere prior to the HTML5 drafts.

XHTML2 had some clever rules (for its "srctype" attribute) that were
similar in effect, yet managed not to conflict with HTTP/1.1.  It would
be nice to see HTML5 adopt some of that language. 

> >> The problem is that (and I have to keep checking this) is that IE 
> >> and other browsers won't let you send in a new @data value via the 
> >> DOM.
> 
> > How is this not a bug? Have you submitted bug reports? (Or are you 
> > aware of existing ones?)
> 
> I think it is a security thing. The host may want to sniff the content 
> returned for @data url. But like I said, I think the main browsers are 
> converging. .

Security?  I don't think so.  That doesn't make any sense.

More likely, no (or perhaps few) browsers have wanted to bother with
implementing shutdown and restart of a plug-in in response to changing
an attribute via DOM. 

And from an implementation perspective, I don't think it's crystal clear
what should happen in that case.  Since "data" is effectively an
initialization parameter, does changing it post-initialization
necessarily mean that it should trigger restart of the plug-in?  Without
a specification saying so, an implementer would be jumping to a
conclusion (albeit not an unreasonable one) in doing that. 

> >> You have to rewrite the entire <object> tag to change the URL. This 
> >> is not true with a player that accepts a url via the <param> (Flux) 
> >> because you can always send in a new url via the src <param>
> 
> > In changing the URI specified in the HTML, you'd need effectively to 
> > restart the plug-in, anyway.
> 
> Me not know but it sounds like that may not work that well.
> I have some examples that script the src param that work fine, 
> However, scripttin @data is another matter. I hope to return to these 
> at some point and see what is actually happening now.

Even a plug-in that supports a "src" param isn't obligated to do
anything if it gets set to a new value post-initialization.  All of this
is completely unspecified.  You don't magically get this behavior with
support for an initialization-time "src" param. 

> > Practically speaking, the result isn't much different from just 
> > replacing the whole "object" element.  If you want to avoid that, 
> > use Browser.loadURL in the SAI.
> 
> Right, and I would like to show some examples of that. AjaX3D did some 
> of everything I have talked about here. .
> http://www.hypermultimedia.com/ajax3d/index.htm

Unlike the solution you're proposing, behavior of Browser.loadURL is
specified.  Where a particular need has been identified, I'd rather see
implementers encouraged to adopt existing specifications that satisfy
the requirement rather than have them (or the W3DC) come up with new
specs. 

> >> >> On the other hand, if src param is used, then the url is sent to 
> >> >> the plug when it is ready and then the plugin asks for the 
> >> >> content when it is ready.
> 
> >> > A correctly written NPAPI plug-in will be ready for an initial 
> >> > stream. Period.  There is absolutely nothing about VRML or X3D 
> >> > that would make implementing this especially problematic.
> 
> It is just a way a normal user would expect to be able to prgrram the 
> thing. For heck's sake it should be easy to send in a new scene That 
> is what those html attributes and params are for - a direct connection 
> to the host DOM.

AFAICT, how a plug-in handles changes to params post-initialization is
completely unspecified. 

-- 
Braden McDaniel <braden at endoframe.com>