The service provider for Elbow is written in PHP and the application and user files are stored in MongoDB.
The Elbow desktop application is written in Adobe AIR.
The AS3 FileManager and FileLoader classes were started and successfully tested.
I decided to use a mixed binary and JSON format for the getFile service result. It returns a big endian short meaning the length of the JSON part of the response, the JSON, and then the octets of the file. Of course, the JSON includes the id, md5, and length of the file to follow.
(I say mixed binary and JSON, but the binary exists only at the logical application level… the web server still encodes the binary for transport as it always does if it has to do it… the mime type is set to application/octet-stream.)
What was sort of interesting was using the flash.net.URLStream class. Usually, one loads data directly into Flash objects so it’s not necessary to get into the middle of the stream, but I need to read those first two bytes and then the JSON in order to provide meaningful event dispatches.
The AS5 Progress event usually shows BytesLoaded and BytesTotal so a Flash application can show a progress bar or something, but the BytesTotal is based on the return from the web server (or Flash Media Server or one compatible with RTMP)… In my case, the “length” property of the JSON object returned as part of the response is used to calculate progress. The web server cannot tell the client how much data it’s sending because the PHP script is still sending it.
It just occurred to me that I could fix that by just telling the web server how much data I’m going to send… then that information gets sent to the client. I’ll do that eventually. ** Well, decided to do that now, but apparently Flash doesn’t care. That’s alright.
So, of course, there’s a custom event object. It’s not really a big deal, but I like that it just passes along the underlying event from Adobe, regardless of that object’s type, and passes along the response object (which includes the things like id, md5, length, mimetype). Downloading files in Flash involves a bunch of different event types and it’s irritating to have to create all those event handlers. The FileLoader class just dispatches one type of event, FileLoaderEvent.
HTTP depends on a timestamp to determine whether or not a file should be sent again. Since MongoDB / GridFS is always storing the MD5 hash anyway, the caller of the getFile service passes in (again with JSON) the id it wants and the md5 of the file it already has (if it has it). The getFile service returns the appropriate status instead of sending the file if the hash in hand matches the hash in the bush.
Files are stored on the client PC in hashed directories with files named just their id and md5. Another mechanism will be employed to know which files are for what.
I say Application Files are stored in MongoDB because the desktop application is just going to be a collection of the most basic classes. Everything else will be maintained by the file manager. Everything else will include a set of widget base classes and widgets. AIR can be set to automatically prompt the user to download an available update, but considering my target audience, I think that’s a little much to ask. Besides, this is much cooler.
Everything happens over SSL and all requests for user files will have to be authenticated by a pre-authorized workstation.
Security is a big deal for the client base, so they can only access the service using the client application after that installation of the client application has been authorized by their administrator. It won’t be possible for a client to access the service from another location without prior written approval of Major League Baseball.
You’re not supposed to get anything out of all this. I’m writing it so I know when I did these things.
Leave a Reply