[X3D-Public] Web3D.org Front Page

[Braden McDaniel]

On 6/23/09 1:23 PM, 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".

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

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.

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

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

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

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:

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

-- 
Braden McDaniel                      e-mail: <braden at endoframe.com>
<http://endoframe.com>               Jabber: <braden at jabber.org>