[X3D-Public] Web3D.org Front Page

[John Carlson]

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