23.2.07. The Saddest Music in the World

The Saddest Music In The World just joined the list of favorites-among-favorites-of-movies.

Surreal, beautiful, soft, and fuzzy, like Institute Benjamenta; but with a classic old showbiz quality and language like Sweet and Lowdown; and a bit of melancholy [even a bit of brutality] like Dogville, Shadows and Fog, and Eraserhead.

It fits in so comfortably with these other films that I love; yet stands on its own in a way that makes me terribly happy as it feels like it glues them all together. It's this one piece that makes all of the above and more (2046, City of Lost Children, etc) all the more lovable.

Isabella Rossellini's beer baroness with the platinum wig is beyond hot. Especially when she shows up with beer filled glass legs.

And Maria de Medeiros is beyond cute as the depression era dark bobbed amnesiac singer and dancer. I guess she's probably best known in the U.S. (if at all) as the wife of Bruce Willis's character in Pulp Fiction. Here, she seems straight out of a Chaplin or Keaton film, while capably leading a spectacle performance of The Song Is You mid film.

I love getting lost in spectacle.


Flex my Dojo

OK. I don’t get Flex. By my understanding, Flex is the components / widgets from or for Flash. Actually, I can’t find a definition. I’m hitting the main pages, and they all treat me like I already know what Flex is and why I need it. But I don’t. From the buzz I see around the web, it smells a lot like the promises of Java Applets circa 1996. It’s the universal platform - rich internet applications! cross platform! run everywhere! It’s in the browser, so you lose yet another tab / window to some application that’s not quite a full application!

As a life long Mac user, I’m dubious of any cross platform promise. Java with some cross platform toolkit or another has never been a great experience on the Mac. Eclipse fares fairly well, but I’m still very aware that I’m in a different environment. This has something to do with look, but really it’s about feel. There’s a way that I expect my widgets to feel: ways that I can move around in a text field, responsiveness of a button, and so on. Cocoa’s text fields benefit from their NeXTStep ancestry which has provided some powerful and extensible features: basic EMacs keys (ctrl-a and ctrl-e to get to begin and end of line, ctrl-k and ctrl-y for kill and yank to a separate copy/paste buffer); spell checking; in place dictionary lookup; often, a common set of search/replace features including ‘use selection for find’; word completion; etc. Input Managers can be installed for even more control. I used an Input Manager to get word completion in early versions of Mac OS X, before it was a built in feature. Now I use “Edit in TextMate” to edit HTML TextAreas, emails (from both GMail and Mail.app), even to tweak a filename using TextMate’s editing tools. Any Cocoa text field, whether it’s a single line or a large block, can be wired this way without the application’s knowledge.

In cross platform toolkits (as well as most Carbon apps), I lose these features. XUL (Firefox/Mozilla); Java AWT, Swing, and whatever the hell Eclipse’s toolkit is called; and now: Flex. Don’t get me wrong: I like that these toolkits enable some apps to exist on the Mac at all; but I’ve seldom been as productive in them as I have been with native apps.

I took a look at a Flex Quick Start page covering “Building a simple user interface” to see basic Flex in action. As I feared, the controls followed a different set of rules than those I expect. Since the tutorial covered only basic UI, there wasn’t much that was terribly impressive. I didn’t see anything that stood out from what I had seen in rich JavaScript/DHTML toolkits like Dojo and YUI.

So I decided to do a quick comparison - how did some of the basic Dojo widgets compare to the basic Flex ones? I went to Dojo’s “See it in action” tab and looked at the FormTour, which housed some basic widgets including one of the few “rich text editors” that works in Safari. And sure enough, even though some of these widgets had some extra behavior wired in, they were still built on browser native elements. All of my usual keyboard behavior worked as expected in text fields - even in the rich editor.

I can see how Flex may be useful for fast dynamic graphical components, such as charts. Beyond that, I feel like it’s another round of the magical cross platform kool-aid; another round of trying to shoehorn a sub-universe within the sub-universe of the web browser. I think it has its uses, but some people seem to think that it’s the new holy grail of rich internet applications.

I’ve heard this song before, and I’ve been horribly disappointed almost every time. So far, all I’ve seen of Flex is a retread of the promises of Java Applets. I would like to see statements about what makes Flex different. Has it learned from Java Applets and the various “abstract” Java toolkits that promised a common UI everywhere? Does it have a focus, or will it devolve into servlets and enterprise architecture? Is Flash still an animation platform, a movie player platform, or a GUI/Form platform? Can it handle all of the above? Will Adobe be wiser than Sun and avoid big clashes with Microsoft?

My gut says not to trust it.

Labels: , , , , ,

13.2.07. An update on Python SOAP toolkits

Last week, I struggled with implementing a rough SOAP service in Zope 3 and Python. At the time, the state of SOAP libraries and toolkits for Python appeared to be in rough shape. The only toolkit that seemed to cover enough ground was ZSI, which also had a recent 2.0 release. ZSI, however, is a sprawling and incoherant mess. Given the SOAP, WSDL, and WS-* specs, who could expect anything more? It was a difficult system to work with as I had to do some brutal massaging of typecodes in order to get my client application to respond.

At the end of last week, TGWebServices appeared on the scene. TGWebServices brings XML-RPC and SOAP to the TurboGears web framework. It looked like it was much easier to use than what I had to cobble together.

And this week, soaplib showed signs of life with a new release. Soaplib appears to be easier to comprehend than ZSI, and it feels more modern. I wish it had been available a week ago.

Labels: , ,

10.2.07. SOAP. Web Services. Flash. Waaa.

As a result of a peculiar chain of events, we’ve been stuck with a compiled Flash file requiring data off of a web service. The old database is gone. The old server is gone. We have been unable to get much information about the data required. We don’t have the Flash source. All we have is a single ColdFusion Component that is used a web service via WSDL and SOAP.

I’ve never used ColdFusion. Fortunately, Allaire, er, Macromedia, er, Adobe makes demos available. ColdFusion even comes with a developer version that can live beyond the typical 30 days. So using that, I was able to re-generate the WSDL. I didn’t understand it, but I had it. Then I installed a demo of Flash Professional. I made a quick document and put some web service links in it by stumbling around, and watched the HTTP/SOAP communication between Flash and Apache/ColdFusion.

I tried looking at the specs for SOAP, and recoiled. Then I naively thought I could emulate the response as a Zope Page Template emitting XML, looping over the little bit of data that the Flash client wanted. But then I realized that the SOAP style in use was RPC style, and the ‘method’ was buried in the posted XML, so I couldn’t even easily answer the incoming requests.

Since there’s no standard SOAP toolkit available for Python, Zope 3 only holds a skeleton off which one can hang a SOAP handling REQUEST/RESPONSE pair. I’m too dumb, or perhaps just too busy, to wrestle with XML parsing myself, and I quickly realized that I needed some kind of toolkit. The data that I saw in the WSDL and SOAP communications appeared far too complicated for me to read and write on my own. Again I tried going to the specs, and again I ran rapidly away as I couldn’t even figure out how the WSDL connected to the SOAP requests and responses.

Now, obviously this stuff must work out for somebody. When we first approached this problem, the advice that we got was along the lines “just put up an XML gateway.” Um, what? I then realized that the tools were probably doing everything and the developers with whom we were communicating never gave much thought to what was going on. Data format? There is no data format - just put up an XML gateway!

I can’t fault anyone for this, per se. We all get abstracted away from something. Many web developers plug along happily without knowing too many details about HTTP. Even when one knows quite a bit about the more advanced or nuanced details of HTTP, one’s not likely to know much about what’s going on at the TCP/IP layer.

While stumbling around Flash Professional, I was a wee bit impressed with how quickly I could make a web service connector, wire it to a table widget, write a quick button-click handler, and could see the results in the table. The ColdFusion Component had its WSDL generated by merely adding ?wsdl to the end of the URL. Since both tools are maintained by Macromedia, er, Adobe, the SOAP messages actually seem to work together.

But my gods, it sucks.

I have been so spoiled by HTML and Python, and by Javascript, CSS, Zope, etc. There’s no end to the value of the web browser’s “View Source” command. With Python, I can read the source of almost any library and figure out its innards if I can’t get answers from the documentation. CSS and JavaScript are equally open to public viewing. One can easily send plain text as results of HTTP calls - I think that if we had designed the system we’re wresting with right now, we would have served some kind of delimited text that any tool could read - even human eyes. This week I realized just how hard it is to make a simple SOAP request by hand, leaving me to use a TCP watcher/proxy to test requests and responses.

Using ZSI from the Python Web Services project, I was able to mash together a basic SOAP Publisher for Zope 3. It doesn’t deal with multipart messages, WS-Addressing or whatever the hell that is, “document/literal”, or even Request argument processing. Well, that’s made available on the Parsed Soap instance from ZSI that’s put on the request. The handlers - the remote procedures / “controllers” / “views” / whatever you want to call them, still have to do quite a bit of work themselves, at least with the Parsed Soap message. This is because, as far as I can tell, one can’t do much without using explicitly build custom types, generated from tools like wsdl2python. Ahhh, this takes me back to all of the crap I had to deal with in ILU/CORBA - baroque generated code that one couldn’t live without, nor was likely to understand.

Even after all of that, I had to do a lot of ZSI typecode wrangling in said generated code before I even began to get results like what was generated from ColdFusion. And these are simple calls, really - no request arguments, and the returns are just lists of dictionaries. I stand amazed at just how much work is involved with getting these little details right, even with a toolkit.

Even with that toolkit’s aid, the status line in FireFox would read “Waiting for data from…” This was puzzling, as I thought had finally mangled a seemingly proper Map and Array typecode / values together from the available tools. I started to worry - is there something at the HTTP level that SOAP is doing differently? Does it want chunked results? Is it not closing the connections? I started crawling deep in the networking guts of Zope and Twisted, trying different transfer encodings, verifying that the content-length header matched the content length in the response … nothing.

Then, on a whim, I decided to try dimensioning my array. ZSI’s array, by default, doesn’t seem to handle specifying some kind of variable length in the array type. So it was generating xsd:anyType[]. The ColdFusion results had xsd:anyType[n] with n being the length of the array. I finally got this working by dynamically altering half of a tuple on a typecode that descended from the strange Result type/typecode that I was building. I’m not even sure if this is thread safe, come to think of it. But by finally getting that dimension in there, Flash started to respond again.

Ugh. Remember, The S Stands For Simple.

That kind of development - closed, compiled, heavily dependent on tools like Flash that work on few desktops and cost a good chunk of money - is just so foreign to me. I’m no die-hard open source zealot: I love a lot of the commercial tools and applications for Mac OS X, and would rather use it than any of the “free desktops”. But when it comes to web development, I’m used to dynamic languages and source code that is often readily available or shareable without the need of heavy tools. This is (usually) code that I can read, which can teach me new techniques by real implementation and not vague “hello world” examples followed by nightmare specs. I’m used to the layers below that being either so lightweight or established that I don’t have to think about them much. I’m grateful that I still seldom have to think in XML. I’m glad that I have next to none of the endless Java acronyms memorized. Sure, I guess there’s a place for them all, but I’m happy that I’ve been able to make a living for the past ten years without all of that. And I’ll be happier still when this particular problem is behind us.

Labels: , , , , ,

7.2.07. Damn Fine Coffee

My David Lynch Coffee arrived today. I won't get a chance to try it until tomorrow. But damn! I'm excited.