Command Proxy - IFBIN 1.0 used it with Python
DIGG IT!
3
Comments
Published
Tuesday, January 22, 2008
at
2:18 PM
.
Mike Chambers posted on using Command Proxy with AIR for .NET integration but having actually deployed a rich client solution cross-platform with IFBIN using this same pattern, I thought I would chime in. First off it works and by works I mean that I successfully built and deployed IFBIN 1.0 on MAC and PC using Flash Player, Flex 1.5, and Python. Here is the architecture atop Mike's diagram.
The reason I chose Python is that it ran cross-platform so porting between operating systems was not as hard ( can't say trivial but 90% of the code worked ) and leveraging Flash Player allowed for a rich UI. When IFBIN 1.0 shipped in 2005, we had no AIR runtime and using Central 1.5 was problematic given the lack of a really solid FileIO feature set. The IFBIN architecture ran a local http/socket server and launched a browser when started. The browser then loaded a SWF file created with Flex 1.5 and opened an XMLSocket connection to the locally running Python server. The Python server in this case handled all DRM, FileIO, Downloading, and Licensing of the files on a per installed basis and the local server had a simple API for executing any feature that Flash Player did not support.
In regards to security, the architecture in IFBIN 1.0 limited client/API access via a secure token and only clients with that token could connect to the locally running service and call the API itself. It also helped because the local connection from ClientUI to local server was a persistant TCP/IP Socket so once authenticated all commands over the socket were denoted as secure. I also made some security enhancements to limit the FileIO to a single directory and thus writing and deleting files was limited to the service and managed.
I personally would avoid building an local .NET dependency into your application as this just limits compatibility. When we write software we want to reach the largest market possible without having to do unique things on a per platform basis. With IFBIN 2.0 (yes it is in development) I am using AIR 1.0 with no external dependencies. This choice makes development cross-platform ideal as I get 3 platforms for free without any additional work.
My take is that the key value of AIR is writing software for 3 platforms (MAC/WIN/LIN) with a single codebase. Anything that forces me to do something unique per platform and fork the codebase is a really bad thing.
To Mike's defense the Command Proxy architecture works well but I would personally never do it again with IFBIN. AIR 1.0 handles all the requirements to deliver IFBIN without a local server/service running.
My 2 cents,
Ted :)
But if AIR does not give you access to something you need, like TWAIN, what can you do?
I am looking at Artemis, but development seems to have been stopped.
Would be great if AIR would provide at least a system execute to do hacks around. If not people will end with solutions like yours...
This is pretty cool to see what you pulled off with Python and the Command Proxy awhile ago. It validates some experimentation I've been working with using Python.
While I think it's nice to build an application with AIR, I still see many reasons to go the route you did with IFBIN using the command proxy, if at least to build applications that can breath a bit more more.
Creating a database browser application/tool, for example, would be big for me and great in the community. Especially leveraging something like Python's SQL Alchemy to dynamically inspect tables, relationships, etc. to build possible code generators or tools of the like (I haven't seriously looked too deep into how this would work on OSX.) But I'm just suggesting the type of idea that a fully capable desktop application could do. Or, what about a media player (more than just flash movies), but something that mixes Flex with cross-platform video players embedded into a window, etc...
AIR can't directly connect to databases. AIR will be good for many applications, but I believe the CommandProxy Idea is quite powerful idea for those of us who need more than the sandboxed AIR can provide. With AIR 1.0, I like the story that Adobe's offering with getting web developers building desktop apps. I'm hoping with AIR 2.0, you can add more features that traditional desktop developers would like.
I'm also not minding the idea of having service that's parsing the commands from flex and running OS level services. Afterall, the same shell that's hosting the browser can host the service, and since it's not a web server or anything that's service up 100s of users, a light-weight service can be pretty reliable for this. But you're right, though, this isn't the architecture for the everyday developer trying to jam out an application in a few months...
I think a lot of cross-platform developers would be happy to get 90% of the way there with an application code base that can run across platforms, and then for the last 10% just stub out interfaces and the like (Adapter Paterns?) to fill in platform specific functionality.
Do you have any insights or links about how Adobe Lightroom is developed? I've read around that it's got a mix of Flex/Flash being hosted somehow for the front-end, some LUA glue, etc...I believe John Nack's blog talked about it awhile ago or something, but nothing in great detail. It would be great if Adobe could share some of it's cross-platform development greatness for some of us other desktop developers that are 1) on time budgets, 2) trying to minimize the amount of c++ code we write, 3) love the UIs we can create with Flex/Flash, etc...
One of the big stories Adobe has going for it in my view, is that as a company, you seem to support both major operating systems equally, with your eyes on supporting Linux. I really like how Photoshop gets released for the Mac and Windows at the same time, compared with say Office 2007 which came out for Windows quite some time ago, and then OSX a year later. Keep up the good work.
Hi Todd,
AIR and Flex using the new ActionScript 3.0 classes could potentially connect to databases. One might use the ByteArray Class in conjunction with the Socket Class to talk to a MySQL Server.
Cheers,
Rob