[X3D-Public] Web3D.org Front Page

Joe D Williams joedwil at earthlink.net
Tue Jun 23 22:27:59 PDT 2009

Hi John,
In reality, the W3C browsers are working better with the <object> 
element than ever before.
If the plugin installs itself with the correct mime(s) and file 
extensions, then it stands a better chance of working than I can 
remember. Also, the browsers are responding better when a .x3d or 
.x3dv link is clicked -- usually opens a new browsing context.

There have been many minor improvements, but one big one was when they 
decided to allow an empty @data attriburte and open the plugin using 
the @type.
You can see how this works, in Flux anyway, by looking at the AjaX3D 

The only problem we are having is that
1: we don't have our own MIME story straingt yet.
2. As far as I know now, X3D browsers haven't settled on a common 
<param> name to pass in a url.

Heck, even Safari works a lot better with X3D players.

Thanks and Best Regards,

----- Original Message ----- 
From: "John Carlson" <john.carlson3 at sbcglobal.net>
To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Tuesday, June 23, 2009 9:28 PM
Subject: Re: [X3D-Public] Web3D.org Front Page

>I hope this is all getting back to the HTML5 folks so they can 
>provide  a standard for all browsers?
> John
> On Jun 23, 2009, at 9: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".
>> No, @data is standard and everybody accepts that.
>> 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
>>>> 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.
>> 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. 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 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. 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>
>>>> 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.
>>>> 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. 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.
>>> 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'.
>>> * 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.
>>> * 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.
>>> 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?
>> Thanks and Best Regards,
>> Joe
>>> -- 
>>> Braden McDaniel                      e-mail: 
>>> <braden at endoframe.com>
>>> <http://endoframe.com>               Jabber: <braden at jabber.org>
>>> _______________________________________________
>>> X3D-Public mailing list
>>> X3D-Public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> _______________________________________________
>> X3D-Public mailing list
>> X3D-Public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org 

More information about the X3D-Public mailing list