[X3D-Public] Web3D.org Front Page

GLG info at 3dnetproductions.com
Wed Jun 24 02:49:24 PDT 2009

Answering my own question, I see about Firefox 3.5 for
Developers. Thanks for letting me know that is what you are
using, now I understand why <object> works for you. But in
my opinion, it isn't acceptable to ask casual users to get
into alpha or beta software, so they can use a world via
<object> tags in Ff while <embed> is much more likely to
work with their installed and stable version (as most people
will simply click Help, Check for Updates). It is difficult
enough to get people to download and install a plugin as it
is. So to recap, IMO my original comment did make sense and
was correct; <embed> is necessary to load worlds in Firefox.
And this, especially if the intent is to place a world or
logo in a home page. Perhaps in a year or more that will be
different. Thanks for the interesting discussions
nevertheless, this was good exercise.


>-----Original Message-----
>From: x3d-public-bounces at web3d.org [mailto:x3d-public-
>bounces at web3d.org] On Behalf Of GLG
>Sent: Wednesday, June 24, 2009 4:25 AM
>To: 'Joe D Williams'; 'Braden McDaniel'; x3d-
>public at web3d.org
>Subject: Re: [X3D-Public] Web3D.org Front Page
>For a starter let me say that I have always used
>'<param name="src" value="load.wrl">' and not
>'data="load.wrl"' except for testing purposes on several
>occasions during the last few days.
>Just installed latest Firefox 3.0.11. Same results as
>before. Using the 'data' attribute simply causes the page
>remain blank. With 'param' Contact 7.106 loaded in Firefox
>but stayed on the startup screen as before (not loading
>world). Installed BS Contact 7.2 and now page just remains
>As far as the type goes, no trick there. I just tried a
>bunch of different types, but I haven't noticed any
>difference whether 'type' is used or not with both IE and
>Firefox, or regardless of what the type referred to
>is. On the other hand I've discovered there are BS Contact
>specific types that could be used to force Contact over
>other plugins, so that sounds good.
>So why doesn't Contact load in Firefox with <object>? Even
>with something as simple as what follows I get the same
>results (never mind nested <object> for now - <object>
>should work by itself in Ff if it is ever expected to work
>while nested):
><object type="model/vrml" data="load.wrl" </object>
><object type="model/vrml"
><param name="SRC" value="load.wrl">
>Tried same with various types and extensions to no avail.
>Here is a copy of the about:plugins output related to BS
>Contact which I've just upgraded.
>BS Contact VRML/X3D 7.205
>File name: npBSContact.dll
>BS Contact VRML/X3D FireFox plug-in
>MIME Type 	Description 	Suffixes 	Enabled
>model/vrml 	VRML 2.0 	wrl,wrz 	Yes
>x-world/x-vrml 	VRML 2.0 	wrl,wrz 	Yes
>application/x-bsContact 	Contact VRML 	bswrl 	Yes
>application/x-blaxxunCC3D 	Contact VRML 	bxwrl 	Yes
>model/x3d+xml 	X3D 	x3d,x3dz 	Yes
>model/x3d+vrml 	X3D VRML 	x3dv,x3dvz 	Yes
>model/collada+xml 	Collada 	dae 	Yes
>model/x-bs-collada+xml 	Collada 	dae 	Yes
>application/x-cc3d 	BS Contact 		Yes
>application/x-gzip-compressed 	Compressed X3D/VRML
>wrz,x3dz 	Yes
>image/jp2 	JPEG2000 	jp2,jp2k 	Yes
>Other things I did:
>* Removed all other x3d/vrml plugins and even re-installed
>Contact - restarted computer.
>* Checked under 'Tools, Options, Applications' to make sure
>BS Contact is the registered app for the vrml type.
>* Also under 'Tools, Options, Main, manage Add-ons,
>BS Contact is enabled.
>* Firefox error console does not show anything wrong with
>the above.
>* In WinXP Pro under Folder Options, File Types, wrl is
>registered to open with BS Contact Player Wrapper.
>I cleared Ff cache and the setting is set to 0MB.
>Once more the server mime types for quick reference:
>model/vrml	wrl vrml
>model/x3d+xml x3d
>model/x3d+vrml x3dv
>model/x3d+binary x3db
>So you tell me again that <object> works in Ff without
><embed>! I'd hope our users don't have to go through this
>much trouble setting up their machine because we would
>probably loose 99.9% of them. Hopefully, this is an
>or mime type issue that I have overlooked. Braden you
>mentioned Ff version 3.5. Was that a typo or are you
>with some beta version?
>>-----Original Message-----
>>From: x3d-public-bounces at web3d.org [mailto:x3d-public-
>>bounces at web3d.org] On Behalf Of Joe D Williams
>>Sent: Wednesday, June 24, 2009 12:23 AM
>>To: Braden McDaniel; x3d-public at web3d.org
>>Subject: Re: [X3D-Public] Web3D.org Front Page
>>>>>  <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
>>> Presumably you mean "that BS didn't recognize the data
>>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
>>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
>>>> recognize
>>>> the src param.
>>>> Anyway in the big view, it is better for a plugin to
>>>> <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 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
>>palyer for the mime in @type.
>>>  Some current and historic implementations might use the
>>> attribute for this purpose; but this is unreliable as
>>> attribute is technically only a hint. (That is, the Web
>>> could opt not to fetch the data at all if the media type
>>given in
>>> "type" were unsupported
>>is in work now, but they are mostly skipping the hard
>>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
>>content type.
>>> I haven't tested it yet, but recent bugzilla.mozilla.org
>>> leads me to suspect that Firefox 3.5 might finally be
>>> this more-or-less to spec.
>>Yes, hard to tell what the spec is because they are sort
>>>> 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
>>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
>>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>
>>because you can always send in a new url via the src
>>>> 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
>>> 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
>>a bit
>>dificult to program.
>>>> In the <param>
>>>> case, the host browser is probably less involved in the
>>>> process.
>>> Well, it's not involved at all in that case--except
>>> though its cache.  That is, the browser is going to
>>> resource specified in "data" *no matter what*.  If the
>>> subsequently uses NPAPI facilities to fetch the resource
>>> with a "src" param, one can hope that this will just be
>>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
>>> provide no different media type information than it
>>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
>>>    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
>>>  * You lose the potential to share cached data with
>>>    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
>>> developer would turn that down.
>>One whose second choice is be be hosted in a web page?
>>Thanks and Best Regards,
>>> --
>>> 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
>X3D-Public mailing list
>X3D-Public at web3d.org

More information about the X3D-Public mailing list