Basically, carry along the version in the URL seems not very RESTful to me. First, it bloats your URL (well, not much but it does) and second if the version of resource change, it does not mean that its location changes as well. In opposite it has to be constant!

To get around this, Peter outlines the concept of custom vendor MIME media types which are enriched by an API version number and changing if the version changes. Great idea! Seems to fit - but wait … He assumes that one has defined his own exchange protocol for ressource representation and manipulation. If so everything goes well. But how about using standard formats? Why? Think about abandoning the hassles with defining an own exchange protocol or your new API and simply wed a standard like the Atom Publishing Protocol (APP) and the REST approach. Since the APP has his own MIME type you can not easily change by enriching it with versioning numbers. Doing so would result in loss of core benefits you wanted to take advantage of: Rely on a growing library of components supporting Atom development in almost any major scripting or programming language while spending less time developing core data exchange functionality - simply because the header is not understood anymore. In my opinion in such a case it may be useful to define a custom X-Header to carry your versioning informations. The question is: How RESTful is this approach? ;). For me it is a tradeoff and i am going to use it to see how thing behave this way.

In the comments Peter states that he is aware of the discrepancy with the standard formats and already thinks about a solution which he is going to publish.

By the way: He also outlines the downsides of his approach and provides some ways to migrate the negative impacts.

I’m looking forward to an interesting discussion.

Best,
Frank

The list of new key features is quite impressive: 3D Effects, Custom Filters and Effects , Advanced Text Layout, Enhanced Drawing API and Visual Performance Improvements. 

With the new 3D-Effects one is able now to rotate 2D-Shapes in a 3D coordinate system. This will boost frameworks like Papervison and so on to the next level for sure. 

Next, the custom filters and effects are slaping into my face. They are arriving in time as i am thinking about how to manipulate designs on shirts in  away that make them look more realistic in product previews. The custom filters saved my day and i can not wait to play around with them. Watch Justin Everett-Church demonstrate custom filters and effects

The advanced Text Layout is a blessing for Flash developers. How often have i heard: “We are not using Flash for {insert heavily text based application} cause the user will not even be able to simply copy and paste or navigate the text and the content team has to consider to much restrictions.” Well, they are right in some points but with the new Text Layout these excuses are not accepted any longer

What also sounds good is the new drawing API. It is promised to get rid of this annoying moveTo()  - lineTo() - moveTo(). In fact i have not seen the new API in the wild yet so i can not state if  there will be a significant improvement but i trust the Adobe guys and really looking forward to get it on my fingertips.

Last important thing to mention: PERFORMANCE IMPROVEMENTS!!! Well at least theoretical. The new Flash Player shifts graphics operations from the CPU over to the GPU which frees the CPU from computing display effects and offers more cycles on crunching numbers for the application logic. It may be a naive assessment of the situation but downloading the FP 10 Beta and visiting papervision3d.org seems to understress my Mac now.

Beside these features a lot of minor improvements like dynamic video playback are made. Have a look at the release notes to get the full list. By looking down that list you may discover two features that are mentioned far to rawly in the common blog posts: RTMFP and File Reference runtime access.

RTMFP (Real Time Media Flow Protocol) brings P2P capabilities to the Flash Player. It is hidden by Adobe itself beneath the “Video Streaming Umbrella”, which surely makes sense for marketing purposes but in fact it has much larger impact. Hank Williams have been doing some extended thinking around the possibilities. While i am not sure if what he outlines will be possible, it’s certainly intriguing thoughts

File Reference runtime access - a feature eagerly awaited by lots of Flash developers. I was often worried about bypassing the limitations and upload local content in the background to let the user manipulate it inside the application.  Loading and saving files at runtime without without thinking about server roundtrips.  With immediate effect i think about letting the user modify their designs they want on their shirts and upload them if they are satisfied or store product previews on their machines.

I am curious about how fast the new version will spread as if it is final. I think especially for ecommerce sites this is a huge opportunity to get their products presented in a way that can make up a great online shopping experience. 

Earlier that that day a note reached me about the first tutorial for creating FP10 content. As there is no tooling available yet the tutorial relies on the nightly build of MXMLC which is the Flex compiler.

Start playing around and contribute!

Best,
Frank 

The first and maybe most important page is the official Flex 4 wiki hosted on adobe.com.  It comes up with an bugtracker, shows the first milestones (first beta scheduled for late 2008 - wOOt) and outlines the first things on the product plan.

Yesterday Scott Evans, a lead developer on the Adobe Flex Builder team, raised his blog “getting and setting” where he is gathering user input for the development of the next Flex Builder. I really like this approach as it shows how serious Adobe takes his mission.

It’s incredible how adobe hurries ahead! No sooner Flex 3 is matured than BlazeDS hit the market. And yes, the product features for Flex 4 not set yet but it is already  available for download. Kudos to the Adobe guys!

Best,
Frank 

Have a look: Verizon media store 

Best,
Frank

I brim over with enthusiasm for seeing Adobe taking this step. When FlasLite hits the first mobiles it was exciting to play around with it but at that time it did’nt make much sense to put efforts in developing mobile application which could only be used by a fraction of the target group because not every mobile vendor got a license for using the FlashLite Player.

After open sourcing the Flex framework removing the restrictions on use of SWF and FLV is the next big step for Adobe to reach more developers and being really cross platform.

Kevin Lynch of Adobe describes the rationale behind OSP in this video. And Ted Patrick is bridging OSP to Duran Duran.

I should immediately start off thinking about designing shirts using the Wiimote. 

It is a really great time to be a Flash developer!

Best,
Frank 

By now Spreadshirt provides a simple listing API that permits you access to some artifacts of your own shop and enables you to create your own front end and get in touch with the Spreadshirt basket. As this is an API for the shop you are not able to create new articles or modify existing ones. If you want to create or buy a neat shirt you have to visit our site and use the T-Shirt Designer.
In the recent past more and more shop partners come up with very sophisticated ideas on how they want to use Spreadshirts logic to get their shirts printed. In some cases they are running some breed of custom shirt designer tool which exactly fits to the needs of their business and they come over to us saying: “Hey! We have this cool tool! We simply send you the text to be printed along with color and size of the shirt and everything should be fine.” At this point my face fades to white, the complex data model for describing a shirt plops into my mind and i find myself saying: “Well, we can do this - but …”

During the preparations for our cooperation with CNN.com i was caught exactly in the situation described above. CNN told their agency to develop an application which shows CNN headlines on shirts and the user should be able to choose the text color and the color, fabric, size of the shirt. When the agency finished the UI part we where asked how they should submit their data. Some conference calls later it turned out that we where not able to explain our data model to them and every further shot only results in more confusion on both sides. So we decided to provide a sophisticated API which comes with the minimum set of required data. The problem seems to be solved but the next was right around the corner: They simply where not able to use the API because they had no idea how to interact with a SOAP web service in Flash. Finaly we boiled it down and offered a solution which satisfied both sides.

Why i’m telling this? Because, the CNN cooperation has learned me some essentials on API design:

1. Your API can offer a thousand possibilities. If it is to complex you will frighten off our potential users.
2. Provide a library for your API which cares about the communication with your interface. This will dramatically lower the entry level for your fellows and raises the acceptance.

There are a lot of reasons for bundling a library to your API but they are not scope of this post. In one of my next posts i’ll try to explain why i’m so crazy about that library support thingy .

Best,
Frank

After 45 minutes of very bad brain wash advertising my mind is bloated with even more questions on Silverlight. Mainly one fact hacks me: Moroney states that one big advantage is the streaming of unprocessed XAML to the client. To me it seems to be a big disadvantage. Streaming unprocessed code to the client always means that the client has to spend CPU time on processing it. I’m not talking about parsing and possible parse errors because i’m sure the MS guys are smart enough to equip the developers with tools to deploy syntactical correct code but it is doubtful if this approach does not lower the user experience. I mean client side compiling always cuts off performance. The application has a longer startup phase. Maybe this is not important for small apps but as Moroney himself used the example of a huge web application where MS Silverlight and it’s streaming code approach satisfied the customer who was a major cat food company which wanted to modify their content easily some questions popped into my mind.

1.  Moroney states: The streaming code approach protects you from recompiling and rededployment of your entitre application as needed in Flash
Maybe he is talking about the Flash IDE. In this case i would agree but in relation to the Flex framework he is completely wrong. Flex supports incremental builds. Ok, deployment is another issue but to be honest - “huge” applications are not one big ball of mud! They should consist of modules and components which are downloaded as they are needed.

2. Moroney states: The XAML code can be generated on server side and the passed over to the client which allows you runtime code manipulations.
This is a good point but as i think of Flex Data Sevices this is no longer an advantage. Also if he would reference only UI-Components i would have to ask for the sprit and purpose of runtime generated UI-Components. Even if he would reference components that are only specific for one in a million use cases i would refer to server side generated MXML which is compiled on server side and downloaded by the client.

3. Streaming source code and client side processing
In my honest opinion this feature is can seriously turn into a bottleneck of your big apps for some reasons. On the one hand transferring source code instead of a precompiled binary can bloat your network traffic. On the other hand making the client responsible to parse and compile the source sounds like potentially loosing performance because of having some overhead on code handling at least at app start up. I must admit that i have no clue about the rendering process of the Silverlight runtime so i may be wrong. If someone has a good explanation for this please let me know!  To me it seems, that the only reason for streaming the source is the aim to easily deploy an application as a desktop app using the Windows Presentation Framework.

Also some other points like the huge plugin size of 5MB of the Silverlight runtime compared to less than 1MB of the Flash Player makes me think.
In the end MS Silverlight does not thrill me. By now i only can see a clumsy attempt to catch up with Adobe Flex and AIR. I’ll keep an eye on it and give it another try when the next version is out.

One important thing i’ve learned from Moroneys presentation: Avoid the usage of online demos in your presentations! You’ll never know if the network is your buddy. 
So in this point i feel sympathy for Laurence.

Best,
Frank