Abdul Qabiz on Web Technologies, Flash Platform, RIA, India

YouTube has announced a lot of new features:-

• Updated API to allow CRUD – Create, read, update and delete – operations
• Upload API
• Chromeless Player
• Player’s JavaScript API
• H.264 videos – Notice the high-quality playback link below videos on youtube

This is really amazing, we can build kick-ass applications that would use YouTube’s platform for media upload, conversion (trans coding) and delivery, seamlessly.

I am yet to confirm, how easy it is to load and control YouTube’s player in our Flash/Flex apps? Controlling loaded SWFs is hard, unless it allows cross-site scripting through Security.allowDomain (”loaderdomain.com”). I hope, some day Flash Player would have more Security APIs, which would let us expose a set of interfaces to loaders (SWF loads another swf from different domain).

In any case, we can overlay iframe/div to show the video. That’s what I am doing for Yahoo! Live Mashup.

Update (March 12, 2008): YouTube’s chromeless player can be loaded in Flash/Flex applications and can be controlled. That’s what I heard Geoff Stearns, Flash Engineer in YouTube and SWFObject developer, saying in this video.

Technorati Tags: youtube, api, crud, upload, video, chromless, player, h.264

Adobe Flash Player Security-Sandbox is very good and we have not heard any major security vulnerabilities so far. However, I think, it can be made more intelligent, I have some use-cases where I can’t do anything.

XMLSocket API is cool, since it’s inception, developers could create cool applications (multi-player games, chat-apps, presence-apps etc). XMLSocket servers (unity, swocket etc) is needed to comply with a specification in order to work with Flash Player (as a client). Since developers are using/creating custom-servers, they could control various things on server-side, f.ex: configuring right security-permissions, serving right policy-file (crossdomain.xml) etc.

With Binary Socket API, in Adobe Flash runtimes, things have changed a lot. Applications (for Adobe Flash runtimes) can now connect to servers using standard protocols (POP3, SMTP, Databases, HTTP etc). Totally cool feature which allows creation of kick-ass applications (Yahoo! Web Messenger, mySql driver etc). But Adobe Flash Player’s security-sandbox is limiting Binary Socket’s capabilities.

I have been working on a library (as3httpclient) to do more things (http-status-messages, http-authentication over GET request, support for more http-methods etc) which are not supported by URLLoader API. This library (as3httpclient) doesn’t work in deployed web-application because Adobe Flash Player’s Security-Sandbox restricts it to.

I have following questions/concerns:-

• When URLLoader (or other such native APIs) can connect on any port, why can’t custom APIs (as3httpclient and others) connect?
• Why can’t Flash Player be little more intelligent to check, if connection is made to a HTTP server? Rules could be:- If connection is requested to same domain and destination-port is assigned to HTTP server, let communication happen. If destination server:port is in different domain, check for valid crossdomain.xml and allow the connection?
• Why doesn’t Flash Player consider to-ports attributes, if policy-file is served over HTTP?

With standards, we expect flexibility. We can’t expect a HTTP server to push policy-file to Flash clients? That’s not standard.

Technorati tags: adobe, flash player 9, security sandbox, binary socket, as3httpclient