> So a loader can be used to communicate with an HTTP Server in a push > model?!!! Is this analagous to the way AJAX web sites push content to > the client?
Loader is for SWF/Image but there are ton of various ways to exchange data in Flash. The Flash Player has supported data exchange since version 4 in various forms. With the current 7 Player you have many options to exchange data: ActionScript Classes: LoadVars XML MovieClip.loadVariables XMLSocket MXML (built atop the above...) mx:Loader mx:Image mx:HTTPService mx:WebService **Others** The usage varies in form and function but each has strengths and weaknesses. In regards to a push model there are 2 primary ways to accomplish this: HTTP Poll with delayed response on server data. The AIM/ICQ Central client used this model with a custom HTTP server. The HTTP poll request would hang until the server had data to push, then the result would return. XMLSocket with true push == Ideal! I prefer the later because it works, is scalable, and you can shape the server side API as needed. There is a limited amount you can do with HTTP as each call is round-trip. With XMLSocket each pipe can send and receive data independently. The naming of XMLSocket is misleading, it should be NullSocket as the only required element is null byte delimiters in the message transport. If you use XMLSocket.onData callback the use of XML is optional and you can pass plain ASCII messages. Most of my server protocols look like this: Server > Client: SYNC 0 1 2 Client > Server: SYNC 1 55 8787 Client > Server: SYNC 1 52 8223 Server > Client: SYNC 0 1 4 Server > Client: SYNC 0 2 2 Server > Client: SYNC 0 1 3 I typically create an array using String.split on the value received and apply it to a function for handling the particular message. In testing this is about 20X faster than using XML as a payload. Parsing XML on the server and client are a huge waste when you typically can make due with far less. Parsing delimited text with String.split is 10x faster than XML parsing in Flash and you do not bloat memory in the player. Using String.split you can still use XML with inner message blocks using 'escape' and 'unescape' on send and receive or using an ASCII character that is illegal in XML like | or others. I have written over 20 XMLSocket servers with Python/Java and in every case, using delimited text was dramatically faster than using XML. For example, I have a simple echo client/server in Flash that can round-trip exchange 1000 messages in 1.3 seconds. You can't do that with HTTP, apache and IIS would explode. In the cases when I used mx:Loader, I was importing SWF files. With the Kiosk app, we were converting media formats. Flex/Flash would call a URL on the local server, the local server would fetch a media resource from the web, convert it to SWF, then return the data to the original loader request. This was essentially a proxy for media conversion of GIF/JPG/PNG/WMA/AnimatedGif. > If so, I'm very curious as to how well this works in practice. (I > suspect the devil is in the details here.) > > The loader documentation says the the url needs to be a swf or a jpg. > Can you send down arbitrary data? If you are using data, it is best to use mx:HTTPService or just use XML/LoadVars, this will allow you to exchange data cleanly. > Is it possible to access the content of a loader as bytes? No. There is no support for ByteArray to enable reading binary data. Central supports this and I could see some amazing uses for this in the regular Flash Player. > Is it possible to access the content of a loader incrementally (up to > bytesLoaded bytes)? No. Loader is really a MovieClip with a light API atop. By default, Loader will stream data into the MovieClip. If you are using SWF, it will do its default file streaming. > Can you detect errors? Can you re-establish communication when there > is an error? (Do you just dynamically create a new, invisble > loader?). Yes although it is a kluge. Determining bytesloaded and detecting load failure is tricky. Flex makes it easier but nothing is perfect. I even think the docs mention a shortcoming of this, not sure. > Do you need to destroy the loader after a period of time to release > the bytes it accumulates? No just calling a different URL handles this. This is a base feature of MovieClip in the Flash Player. > The benefit of this over XMLSocket would be: > > - Avoids issues of (client) firewalls with the use of an arbitrary > port/protocol for XMLSocket This is not true, you can run XMLSocket over port 80! Support for low ports was enabled in 7,0,14,0 within crossdomain.xml files. XMLSocket works directly through firewalls without issue. In most cases the client side (behind the firewall) is initiating the connection so there is no issue at all. If you use port 80, this gets even cleaner. > - Simply need to setup a servlet to handle a URL rather than configure > a service to handle commmunication over a port. This is true, but the HTTP overhead on the server can kill things with lots of users. Compared to a tuned socket server with a simple protocol, there is no comparison. We hosted over 20,000 concurrent connections to Jabber via Flash. This would have crushed a web server. We ended up making servers just to support the socket connections and multiplexed the data into single Jabber server. We had 3 BSD servers running the Python XMPP proxy for socket connections and 1 BSD server running Jabber. The 3 connection servers were load balanced via a Foundry switch. True push is only possible with XMLSocket, you can simulate it with HTTP but it is troublesome and not as scalable. Cheers, Ted ;) -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
