[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
examples:
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,
Joe
----- 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