[X3D-Public] Web3D.org Front Page

[Joe D Williams]

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

Well it is not like the plugin has to accept or use @data. It is a 
choice.

>
> "data" *is* standard; but what Lauren has described suggests that it 
> doesn't work with Contact.  I don't have Contact here, so I can't 
> test it myself.  But if this is accurate, I can't say I find it 
> *that* shocking.  If one were to bolt an NPAPI interface onto an 
> ActiveX control, it is the sort of thing that could get overlooked 
> (because it is a way in which ActiveX containers differ in behavior 
> from NPAPI hosts).

I believe it. I saw where IE9 will do something different with 
ActiveX?

>> 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 does so mostly because it is primarily an ActiveX control.  I 
> think Contact and Cortona are in the same boat there.

Well, I think in practice it is just tthe way that it works. 
Regardless, the <object> has some attributes and some custom params. 
In order to use the custom params the plugin must agree. The best way 
is when the plugin gets running, then the appropriate attriburte 
values and the custom parameters are passed to the plugin.

> IIRC, the ActiveX container has some special awareness of the "src" 
> param and it gets some special handling.

Maybe so. That would make it easier as in <embed> but it can be 
anything, like movie or whatever.  But it is not automatic, maybe it 
should be another name, and the plugin must set it up. The DOM will 
follow and create the requested interfaces but won't bother checking 
if the <param>s in the user code match up.


>> >> 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 strength of finding a registered 
>> player for the mime in @type.

Some typos in the above, but yes, the plugin will start with emtpy 
@data if the @type is recognized. This is good.

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

True, with one exveption, if it doesn't recognized teh #type then it 
goes to fallback.

>> http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt
>>
>> is in work now, but they are mostly skipping the hard parts.

I meant that is fine but I think it is mising how to sniff multiple 
media.

> If one simply configures the Web server to send the correct media 
> type, what's described in that draft is rendered moot.

True, although the content type header should be damaged and that 
procedure serves as a recovery. It is real life for W3C browsers. That 
procedure really does not cover many types of embedded content, but 
that is OK by me.

> And note that, should this draft proceed to RFC status, it 
> wouldpresumably need to update RFC2616 (HTTP/1.1).

Well, if not updated, the difference is noted.
The important point is that so far, the @data attribute is sort of 
special.

>> 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.
>
> It is true as far has HTML 4 is concerned.

Not in practice that I see lately, although as usual, I should check.
The main idea is that there is no point in holding up starting the 
plugin until the content has been fully sniffed. As soon as you know 
you have a recognized @type, start the handler.. Then if the url is in 
@data, the host can go ahead and start sniffing the content and hand 
it over when it is satisfied. In general this sniff perfomred by the 
host is of no practical use to the X3D plugin.

>>  Preferably the host will start the plugin if it recognizes the 
>> mime even if the @data is blank and there is not a defined <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 problem with this is HTTP/1.1, which specifies that the 
> Content-Type sent from the server must be honored.  So, in order to 
> conform to that specification, a Web browser that loaded a plug-in 
> based solely on the "type" attribute would then have to *unload* the 
> plug-in and load a new one in the event that the type sent from the 
> server differed from that specified by the "type" attribute.

That sounds too complicated to be efficiient but is actually a use 
case, i think, whenever the response content type is different than 
expected. What to do? If the plugin cna handle teh mime, then proceed. 
But you, as the plugin, why do you need all that sniffing? There is no 
security risk that I know of, so why not just send te plugin whatever 
the response is.

In practice it does not happen that way all the time. Essentiallly the 
minimum  <object> to get a plugin going is:
<object type='modelx3d+xml'>
</object>

The registered plugin should start up, report in, and accept any 
attributes and <param>s.

>
> That's a lot of overhead to incur.
>
>> The problem is that (and I have to keep checking this) is that IE 
>> and other browsers won't let you send in a new @data value via the 
>> DOM.

> How is this not a bug? Have you submitted bug reports? (Or are you 
> aware of existing ones?)

I think it is a security thing. The host may want to sniff the content 
returned for @data url. But like I said, I think the main browsers are 
converging. .

>> You have to rewrite the entire <object> tag to change the URL. This 
>> is not true with a player that accepts a url via the <param> (Flux) 
>> because you can always send in a new url via the src <param>

> In changing the URI specified in the HTML, you'd need effectively to 
> restart the plug-in, anyway.

Me not know but it sounds like that may not work that well.
I have some examples that script the src param that work fine, 
However, scripttin @data is another matter. I hope to return to these 
at some point and see what is actually happening now.

> Practically speaking, the result isn't much different from just 
> replacing the whole "object" element.  If you want to avoid that, 
> use Browser.loadURL in the SAI.

Right, and I would like to show some examples of that. AjaX3D did some 
of everything I have talked about here. .
http://www.hypermultimedia.com/ajax3d/index.htm

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

It is just a way a normal user would expect to be able to prgrram the 
thing. For heck's sake it should be easy to send in a new scene That 
is what those html attributes and params are for - a direct connection 
to the host DOM.

>> 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.
>
> No, that's not what an initial stream is.  The initial stream is the 
> resource specified by the "data" attribute.

If you choose to use the data attribute, then it is your choice.
If you choose to set up a custom param to accept urls, then that is 
also your choice. My experience says it works best for the simple case 
to ignore @data and set up a custom <param>. What can I say, it is 
just more fun.

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

> Please reread above, esp. the "uses NPAPI facilities" part.

This is why it is important that X3D browser makers get concensus on 
what param to use. Since Flux used src, so should all the rest, I 
think. Or pick something else more descriptive of X3D, like maybe 
scene for the url param.

>> This is not important until you understand little details about how 
>> object works.

> I am very familiar with the details of how object works and how it 
> is specified.  You seem to be focusing on the strengths and 
> weaknesses of a particular implementation (Flux) and drawing 
> conclusions about how things should be standardized based on them. 
> I fully appreciate the need to articulate pragmatic solutions that 
> work today.  However, the specification of future standards needs to 
> take into account current standards as well recognize what 
> shortcomings in current software are solvable problems.

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

I know little of internal details,

> There are better ways to do that: you can abstract the resource 
> fetching subsystem such that it can be arbitrarily backed either by 
> a Web browser's facilities or something else.

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

> I can appreciate that in some cases pragmatic concerns may override 
> what is normally the path of least resistance to providing an 
> optimal user experience.  But those are not the sorts of cases that 
> should be catered to when establishing standards and conventions.

>> >  * 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.
>
> Not unless you're talking about some cache that is external to all 
> of the programs we're talking about (which would miss the point 
> entirely).
>
>> > 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.

Maybe it works better now than then. Maybe that is why the X3D 
standard is silent on this. I will try to check. I think the host W3C 
browsers may have to make the same sorts of choices, depending upon 
how much they want to depend upon the OS services?

>> One whose second choice is be be hosted in a web page?

> As noted above, you can abstract the resource fetching subsystem and 
> have the best of both worlds.

Great! All I know is that the reality of it is that <object> is easier 
to use that ever but I need to revive some old examples and figure 
again what part is real and what is wished for.

>
> -- 
> Braden McDaniel <braden at endoframe.com>
>

Thanks Braden, I'm just about to go through a cycle of testing with 
latest IE, Ff, Saf, Chr, and Op along with some X3D browsers. If there 
is a simple way to get yours going I would try. I any event I will 
share the examples.

Thanks Again and Best Regards,
Joe