[X3D-Public] Web3D.org Front Page

Braden McDaniel braden at endoframe.com
Wed Jun 24 19:04:50 PDT 2009

On Tue, 2009-06-23 at 21:23 -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.

"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

> 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.

IIRC, the ActiveX container has some special awareness of the "src"
param and it gets some special handling.

> >> Flux
> >> did, so we used both to cover all.
> >> I haven't checked now whether BS or Octaga, and Instant will 
> >> recognize
> >> the src param.
> >>
> >> Anyway in the big view, it is better for a plugin to use the 
> >> <param> and
> >> drop using @data, if possible. One reasin is that the host browser 
> >> may
> >> treat the content differently if requested in data attr rather than 
> >> the
> >> src param.
> >
> > Er, no.
> >
> > If you don't use the "data" attribute, there's nothing to indicate 
> > to the Web browser that it should start the plug-in. .)
> Uh no, what actually happens, usually, is that if data is empty the 
> the plugin will be started on the stregth of finding a registered 
> palyer for the mime in @type.
> >  Some current and historic implementations might use the "type" 
> > attribute for this purpose; but this is unreliable as the "type" 
> > attribute is technically only a hint. (That is, the Web browser 
> > could opt not to fetch the data at all if the media type given in 
> > "type" were unsupported
> http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt
> is in work now, but they are mostly skipping the hard parts.

If one simply configures the Web server to send the correct media type,
what's described in that draft is rendered moot.

And note that, should this draft proceed to RFC status, it would
presumably need to update RFC2616 (HTTP/1.1).

> 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.

>  Prefereably the host will start the 
> plugin if it recognizes the mime even if the @data is blank and the is 
> not a <param> with a url.
> This is desired because then you can wait to see if the plugin is 
> running before sending it a url.

The problem with this is HTTP/1.1, which specifies that the Content-Type
sent from the server must be honored.  So, in order to conform to that
specification, a Web browser that loaded a plug-in based solely on the
"type" attribute would then have to *unload* the plug-in and load a new
one in the event that the type sent from the server differed from that
specified by the "type" attribute.

That's a lot of overhead to incur.

> The progblem is that (and I have to keep checking this) is tht 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?)
> You have to rewrite the entire <object> tag to change the URL. This is 
> not ture 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.  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.

> >> 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.
> Right, The host gets the plugin running, then when the plugin is 
> ready, the host sends attributes and params. It is nice that the 
> browser can start the plugin without a content file. However, unless 
> the plugin can accept a url cvai a param, the object tag si a bit 
> dificult to program.

No, that's not what an initial stream is.  The initial stream is the
resource specified by the "data" attribute.

> >> In the <param>
> >> case, the host browser is probably less involved in the loading 
> >> process.
> >
> > Well, it's not involved at all in that case--except potentially 
> > though its cache.  That is, the browser is going to fetch the 
> > resource specified in "data" *no matter what*.  If the plug-in 
> > subsequently uses NPAPI facilities to fetch the resource associated 
> > with a "src" param, one can hope that this will just be a cache hit.
> These are separate operations, not the same. The process the browser 
> uses to get content specified with @data is different than the proces 
> when the src <param> is used.

Please reread above, esp. the "uses NPAPI facilities" part.

>  THis is why it is important that X3D 
> browser makers get cnsensue on what param to use. Since Flux used src, 
> so should all the rest, I think. Or pick somehting else. This is not 
> important until you understand little details about how object works.

I am very familiar with the details of how object works and how it is
specified.  You seem to be focusing on the strengths and weaknesses of a
particular implementation (Flux) and drawing conclusions about how
things should be standardized based on them.  I fully appreciate the
need to articulate pragmatic solutions that work today.  However, the
specification of future standards needs to take into account current
standards as well recognize what shortcomings in current software are
solvable problems.

> > Keep in mind, though, that in such a case, the NPAPI call will 
> > provide no different media type information than it would have for 
> > the initial stream.
> >
> > As you suggest, it *is* possible for the plug-in to provide its own 
> > resource fetching machinery.  But there are a lot of downsides to 
> > that--and not many upsides as far as I can tell:
> Sure, it can run 'standalone'.

There are better ways to do that: you can abstract the resource fetching
subsystem such that it can be arbitrarily backed either by a Web
browser's facilities or something else.

> >  * The Web browser's fetch of the initial stream becomes entirely
> >    wasted.
> >  * You end up writing a lot of code for facilities that are provided
> >    by the host Web browser.  If you provide a sophisticated cache 
> > like
> >    modern Web browsers do, we're talking about *quite* a lot of 
> > code.
> >    So, more initial development time, more cost to maintain, and 
> > more
> >    potential for bugs.
> Right, it is just one way to do it. Some X3D browsers want to be very 
> self-sufficient.

I can appreciate that in some cases pragmatic concerns may override what
is normally the path of least resistance to providing an optimal user
experience.  But those are not the sorts of cases that should be catered
to when establishing standards and conventions.

> >  * You lose the potential to share cached data with other services
> >    provided by the Web browser.  For instance, consider an image
> >    referenced from an HTML page that subsequently gets used as a
> >    texture in an X3D world.
> If the URL is the same, then there may be some chance of reusing it.

Not unless you're talking about some cache that is external to all of
the programs we're talking about (which would miss the point entirely).

> > If the plug-in just uses the NPAPI facilities for resource fetching, 
> > it gets to take advantage of pretty thoroughly tested code that 
> > includes a sophisticated cache.  I'm just not sure why a plug-in 
> > developer would turn that down.
> One whose second choice is be be hosted in a web page?

As noted above, you can abstract the resource fetching subsystem and
have the best of both worlds.

Braden McDaniel <braden at endoframe.com>

More information about the X3D-Public mailing list