Jesse Ezell Blog

http://sessions.mix06.com/

Joe Orbman sent me the following email, which I thought I would pass along. Great news.

I thought this would be of interest to you. We just launched a public beta of the 2.1 version of our product - WebORB, the new release is a full implementation of Flex Data Services for .NET. We have added AMF3 support and now anyone using Flex on the client-side can integrate it with the .NET backend. Currently we fully support the RPC services functionality from FDS and are working on adding Messaging and DataService. Essentially, WebORB will become a .NET implementation of FDS, and anyone using Flex Builder can continue to develop the client side there.

There are a few articles describing the integration: First is an overview of creating a Flex application and wiring it up with the .NET side. You can access the article here: http://www.themidnightcoders.com/articles/flextodotnet.htm

The other article describes a new feature we added for Flex clients. The feature enables developers to fetch any type of object from the server, modify its contents and then automatically sync the changes from the Flex application into the original object instance on the server-side. The feature is called object auto-update. There is a live example, client and server-side code in the article: http://www.themidnightcoders.com/articles/objectautoupdate.htm

Ok, it's a month late, but you can download the Flash 8 Specs from Macromedia if you haven't already. http://www.adobe.com/licensing/developer/

I would think that this is good news for anyone who uses Sun products.

My latest project that is taking up all my blogging time is very slick. I think it's safe to say we will blow all our competition out of the water once again :). In any case, we are doing a lot of AJAX communication with the server. I really liked the way Microsoft approached AJAX in ATLAS by using WebService calls to communicate back to the server, so I wanted to follow a similar approach with Articulate Online. The problem though is that there isn't a standard way to make webservice calls in the browser yet. Atlas will support this, but Atlas is still beta :(. So until then, there is a cool lightweight SOAP/WSDL javascript lib that you might want to check out:

Ok, Mesh got mad at me and posted his own thoughts in response:

Well, I tried to post in the comments on the site, but they didn't seem to take.

Here is what I think is a more accurate and relevant comparison between Flash Player 8.5 and WPF/E.

Programing Support
----
Flash : Heavy (ActionScript 3, MXML / Flex Framework)
WPF/E : Heavy (C# / XAML / .NET)

3D Support
----
Flash : None. Some limited hardware acceleration
WPF/E : None (don't know about hardware acceleration.

Declaritive Programming Support
----
Flash : Yes. MXML
WPF/E : Yes. XAML

Bitmap Effects Support
----
Flash : Yes. Medium - extensive
WPF/E : Assume yes

(Flash has pretty extensive bitmap effects and filters. I am not as familiar with .net on this)

Animation Model
----
Flash : Timeline and programatic. Both authortime, and runtime.
WPF/E : Trigger-based: timelines control the animation, but the timelines are controlled by triggers;

Timelines Required:
----
Flash : No
WPF/E : No

Cross platform Support
----
Flash : Extensive
WPF/E : Committed to Mac and Windows (MS doesn't have good track record with cross platform plugins / support).

Drawing Tools
----
Flash : Heavy
WPF/E : Low to Medium (I put low since the tools are not released, and there is not a market of designers using them yet).

Availability
----
Flash : Summer 2006
WPF/E : First half 2007?

You can find more info on Flash Player 8.5 and Flex at labs:

http://labs.macromedia.com

mike chambers

1) The Flash runtime doesn't really have MXML support, MXML is something you compile into SWF. I assume XAML support in WPF/E is going to be runtime, not authortime.

2) Programming support in WPF/E is way better than anything in SWF. WPF/E will support ANY .NET language as long as it meets a few requirements. IL is far more powerful and flexible than what the ActionScript bytecode model allows. Additionally, you will be able to use both VS.NET (which is undoubtedly the BEST dev environement there is), Sparkle, or even notepad and a command line compiler to create your stuff.

3) Cross Platform Support: Mac and Windows is enough for a 1.0. There is nothing really preventing MS from providing Linux, Windows Mobile, etc. support down the road, but you can't expect all those in 1.0. If a Linux user really wants to use it, they can install WINE (and most Linux users are advanced enough and have enough time on their hands to do such things if they haven't already). Probably a moot point anyway, since Andrew Stopford points out that "Linux and Solaris support partnered with third party to do." Outside of the desktop, you really are dealing with a different beast and probably need different designs anyway, but Macromedia's support isn't exactly the best thing since sliced bread in that arena.. last time I checked, there still isn't a player for my Windows Mobile 5.0 phone, and its been out for quite some time.

4) Drawing tools: Drawing tools aren't really as important with WPF/E, because it is about creating applications. With Flash it is a huge deal, because Flash is about creating pretty movies... that said, it's not like Sparkle is a piece of crap.

Some things to consider as well:

5) The SWF format is far more closed to 3rd party devs, as it requires getting the specs and building your own SDK or buying one from a 3rd party. Since Macromedia doesn't have SDKs available for SWF generation and takes forever to get the specs out, Macromedia is always two steps ahead of any 3rd party content producers.

6) If you are going to point out the availability of drawing tools and people with experience using them as such an important part of your comparison, then you should be fair and add the availability of Microsoft dev tools and the legions of Microsoft programmers that are out there. As this is about creating applications, not drawing cute little movies, an army of developers is far more significant that the comparatively small number of Flash UI designers. Not only are there legions of MS devs, but there are legions of MS devs that will be using the exact same IDE that they will be able to use to create WPF/E content. The similarity between WPF/E and WPF is hugely important, as it means that developers could provide both a rich web client and a full desktop client while reusing a lot of the same code (or transition from a web to desktop client for that matter).

7) Video support: Both support video, but with WPF/E supposedly supporting WMV across platforms, that could really be great for content providers if MS decides to add DRM capabilities in WPF/E 2.0. MS DRM is proven and trusted by a lot of media companies that would never think about offering their content as FLV. This is not to mention that there are a free tools directly from MS to create WMV content, but things like On2's video codec or Sorenson's H263 codec were not written, owned, or designed by Macromedia, so they can't really guide those technologies and don't have free tools for creating them. Why do we really need a completely different proprietary video format from a different company every other Flash release? If Macromedia is really serious about video, why can't Macromedia bite the bullet and hire some people with brains to write their own video codec instead of licensing everyone elses?

The lines have been drawn, and a lot of interesting talk is going on.

Jon Galloway has the best description of WPF/E I've seen yet. Most interesting details: