There's nothing stopping you from using Hemlock for just the client-server communication and doing all your UI work in HTML/CSS/JS. You could essentially do a Facebook chat or a Meebo, but using flash-run XMPP communication instead of AJAX or crazy iframe polling.
but the client-server communication is what requires flash, does it not? i thought the point of this framework was to implement comet-style communication but use flash.
platforms (like any non win/linux/mac os or the iphone) that don't support flash can't use applications developed with this because there will be no client-server communication.
If you're using this as only a slice of your app stack, instead of the whole stack, it's easy to build a failover to AJAX. The same way you have Javascript degrade gracefully to HTML, you could have the Flash degrade gracefully to AJAX.
They use flash for display and XMPP polling with ejabberd on the backend. I can understand some of the motivation for this now, but I wonder how much will be obviated by HTML 5 with server-sent events and Web sockets. I guess it will depend on how quickly those things make it into IE.
This architecture works well for event based apps. For more flexibility though you should make sure the logic is in Javascript on the client and just use Flash to keep the socket open managing the xml snippets to the ejabberd server. As long as you are not pushing a lot of data between Flash and Javascript via ExternalInterface the performance is pretty good. Hopefully the need for the Flash bit will go away if Web Sockets makes it in HTML 5 (http://dev.w3.org/html5/websockets/)
If anyone is interested in real-time client-server communication without throwing away your favorite framework. Orbited may be a good fit for you. Sockets in javascript. Check it out:
So it seems that this depends on a persistent connection between the user's browser and the server. Isn't there a problem with scaling with regard to the number of open connections that the server must now maintain?
