Let's try to stay focussed on this issue. so we're looking at either ...
re-implementing the flash:stream element handling , which is a nonconformant kludge. implementing an http based solution or externalizing the XMLSocket stream handling , using a component. I'd prefer that we not compel the flash player to utilize http polling. My experience w/ this, using Flash as a CRM client, is that the Flash player requires a relatively long interval to create & destroy an http call. This is compounded by any XML parsing that might accompany the transaction. You're testing your luck when attempting to poll and parse xml responses at closer than a 5 second interval. I question whether a polling solution would even be viable in certain embedded environments, due to this behavior. Frankly If polling were the chosen approach, I'd have to develop a component to handle streams. The XMLSocket object does transmit simple strings. This might provide a work-around for the stream element issue, but I'd want to confirm future support for this 'feature' w/ macromedia. D _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
