Wednesday, June 15, 2011
Torey Pudwill
Drops the best inspirational video of 2011. Back-lip, kick-flip, back-lip. Massive lazerflip. 360 kick-flip over bench. Kick-flip into waist-high back-smith. What?!
Wednesday, January 12, 2011
RTMFP and FMS on AWS
For the folks out there who would benefit from the full RTMFP Groups functionality provided in FMS 4 but who balk at the up-front server licensing fees, there's a new path to potential fame and fortune:
- Grab the developer addition of the FMS 4 server (get the trial) and a client-side dev tool of your choice, with my strong recommendation being Flash Builder.
- Develop your world-changing P2P application.
- Deploy your server-side logic to an FMS 4 instance(s) on AWS:
http://www.adobe.com/products/flashmediaserver/amazonwebservices/
Also, Jozsef has a great new(ish) article up that discusses strategies for fall-back to handle the situation where clients who wish to establish a direct P2P link may fail to due to poorly behaving NATs or firewalls. FMS on AWS will happily support both RTMFP and RTMP/T/S/E clients and is a great place to put Jozsef's strategies into practice!
Sunday, October 31, 2010
Saturday, October 30, 2010
MAX 2010
My colleague Asa Whillock and I presented a session at MAX 2010 this past week. The session was recorded and the video as well as the slide deck is already publicly viewable at the MAX archive site. The session was titled Secure Enterprise Video Streaming with Flash Media Server and P2P and that does a fair job of summing up everything we covered.
If you're curious about the new RTMFP protocol support in FMS 4, how that's allowing us to really take advantage of the beautiful scaling story with IP or P2P (application-level) multicast as well as the fusion of both at the same time, and how we're putting it to work within Adobe right now, watch the session and take the server for a spin.
If you're curious about the new RTMFP protocol support in FMS 4, how that's allowing us to really take advantage of the beautiful scaling story with IP or P2P (application-level) multicast as well as the fusion of both at the same time, and how we're putting it to work within Adobe right now, watch the session and take the server for a spin.
Wednesday, September 9, 2009
D
Wishing I had the free time right now to really play with D2... Andrei Alexandrescu published a nice, reasonably brief, overview at Dr. Dobb's earlier this year, and it's definitely worth the read.
Wednesday, February 4, 2009
Mission One
Maybe it's time to dust off the motorcycle helmet, boots, and gloves languishing in the garage and get that motorcycle license I was planning on two years ago...
Not that I have the spare change, or the spare time, and I do have a young daughter to consider, but wow. The world's fastest all-electric, from Mission Motors of San Francisco.
Not that I have the spare change, or the spare time, and I do have a young daughter to consider, but wow. The world's fastest all-electric, from Mission Motors of San Francisco.
enums
Back in the FDS (Flex Data Services) days we were stuck supporting Java 1.4.x. Hence, no enum support because they weren't available in the language until 1.5. But things changed awhile back when BlazeDS and LCDS up'ed their base supported JVM to 1.5.
However, just because we could now support enums in the JVM at the server didn't mean anything to the AVM (ActionScript Virtual Machine) at the client.
ActionScript (and ECMAScript) doesn't provide a native enum type. To complicate matters futher, the flash.utils.IExternalizable interface doesn't provide the writeReplace() and readResolve() hooks that the java.io.Externalizable interface defines. When you're deserializing a raw byte stream into an object graph, you need a readResolve() in order to handle enums (singletons).
Java enum serialization can't be overridden at the server, which is good! It's good because this means that enums are always serialized and deserialized according to a consistent recipe. When they're serialized in Java-land (ignoring AMF for a moment), their String name value (as returned by the name() method) is all that's written to the byte stream. When they're deserialized, a single String value is read from the byte stream and passed to the enum's valueOf() method. The returned singleton instance is then readReplace()'ed into the resulting object graph.
Based on this behavior, BlazeDS and LCDS send Java enums to your Flex app as Strings. If the client needs to send an "enum" to the server, send the String value for the enum, and it'll be unpacked as the desired Java enum instance at the server.
But some folks want more than a simple String at the client. As I mentioned earlier, lack of native enum types in ActionScript coupled with lack of a readResolve() hook on flash.utils.IExternalizable makes this impossible. On top of that, when the Java enum instance is written to the AMF byte stream at the server, the AMF type prefix is for the native String type. That means the server-side type name for the enum isn't included in the byte stream so attempting to use registerClassAlias() or [RemoteClass(alias="...")] is futile (and you wouldn't want that anyways without a readResolve() hook at the client).
If you're deadset on representing these values as typed singleton instances at the client, you'd have to do something wacky like manually traversing the data returned from the server (i.e.: a RemoteObject result) and replacing your "enum" Strings or some other marker in the result with the corresponding client-side singleton type instance of your own making before anything else got its hands on the data. That's a lot of brittle data munging for very questionable payoff...
Perhaps at some happy point in the future we'll have a native enum type to work with at the client, but until then my recommendation is to take a deep breath, relax, and just work with Strings (along with defining matching String constants that you can use for data validation, assignments, and equality checks where it makes sense).
However, just because we could now support enums in the JVM at the server didn't mean anything to the AVM (ActionScript Virtual Machine) at the client.
ActionScript (and ECMAScript) doesn't provide a native enum type. To complicate matters futher, the flash.utils.IExternalizable interface doesn't provide the writeReplace() and readResolve() hooks that the java.io.Externalizable interface defines. When you're deserializing a raw byte stream into an object graph, you need a readResolve() in order to handle enums (singletons).
Java enum serialization can't be overridden at the server, which is good! It's good because this means that enums are always serialized and deserialized according to a consistent recipe. When they're serialized in Java-land (ignoring AMF for a moment), their String name value (as returned by the name() method) is all that's written to the byte stream. When they're deserialized, a single String value is read from the byte stream and passed to the enum's valueOf() method. The returned singleton instance is then readReplace()'ed into the resulting object graph.
Based on this behavior, BlazeDS and LCDS send Java enums to your Flex app as Strings. If the client needs to send an "enum" to the server, send the String value for the enum, and it'll be unpacked as the desired Java enum instance at the server.
But some folks want more than a simple String at the client. As I mentioned earlier, lack of native enum types in ActionScript coupled with lack of a readResolve() hook on flash.utils.IExternalizable makes this impossible. On top of that, when the Java enum instance is written to the AMF byte stream at the server, the AMF type prefix is for the native String type. That means the server-side type name for the enum isn't included in the byte stream so attempting to use registerClassAlias() or [RemoteClass(alias="...")] is futile (and you wouldn't want that anyways without a readResolve() hook at the client).
If you're deadset on representing these values as typed singleton instances at the client, you'd have to do something wacky like manually traversing the data returned from the server (i.e.: a RemoteObject result) and replacing your "enum" Strings or some other marker in the result with the corresponding client-side singleton type instance of your own making before anything else got its hands on the data. That's a lot of brittle data munging for very questionable payoff...
Perhaps at some happy point in the future we'll have a native enum type to work with at the client, but until then my recommendation is to take a deep breath, relax, and just work with Strings (along with defining matching String constants that you can use for data validation, assignments, and equality checks where it makes sense).
Subscribe to:
Posts (Atom)