Tags

Quicktime

February 27th, 2007

I have to say I never liked this Quicktime stuff, but within 5 days this changed completely!

Saturday I’d been looking using the freshly updated Firefox (2.0.0.2) at the Quicktime presentation of the iPhone. I already was determined to buy one - if it will ever come out here - I just wanted to play with this animated presentations a bit while sipping on my coffee.

Firefox crashed.

As it had been once helpful I even accepted Microsoft’s offer to tell them about this problem. In the meantime I restarted Firefox and reproduced the crash, filed the quality feedback and learned by then that the problem had been caused within Quicktime. OK, first blow.

I downloaded the latest version (QT-only!) after uninstalling the old one - the process alone is tacky -and everything was OK. I even told Microsoft that Firefox is not the problem but an update of Quicktime will do.

This morning the Apple Updater (I didn’t remember I asked for something lie that to be installed) asked for an Update. Apple makes the life easy. You don’t have an other choice than accepting or declining. You can’t customize the update (which happened to install iTunes in my case) and it gives you no information why you should accept it.

Well perhaps I still want an iPhone, because a care-free handheld device that works and manages itself is what I want - but the faint idea to get me an Apple notebook disappeared completely from my mind (this is why I write this down here, so that I never forget)

XJava-Applet

March 22nd, 2006

Some new idea for a project that came from a problem I encountered at work.

A client uses our web-application at remote sales-points. By remote I really mean remote. The connection is via a X25-line with some 40kbps (bits not bytes!) and a significant latency. We did some tweaking on the Apache to set Expiry and compression so that we have now reasonable response-times.

So far so good. Or not? We had been thinking of moving to an Applet or even a WebStart application instead of a browser based solution. Browser is not browser, for example we had a mysterious bug with IE and Apache when a cached paged tried to load a non-existent JS-resource - the HTML-response got inserted …

Our main goal is to use the same codebase for the applet/webstart as for the server, which will allow more efficient testing and debugging and also avoid duplicate implementations of functionality once in Java once in JS.

At FJA we had an Applet-client which was a bit problematic because it virtually refreshed itself after each keystroke. Our current application has a different approach  that minimizes the number of communications. Though this seems nice, it causes long delays on transitions in the workflow and besides that it makes the data-exchange between client and server very complicated.

Ajax is not really an option perhaps, since we have quite complex rules and many inderdepencies in our UI - the management code we have right now is perhaps already beyond the limit of complexity we can handle, since its JS; we need either other developers who can cope with JS-projects having >200kloc or we put it into something “engineerable” - like Java.

But the communication problem persists. Having simpler exchange means having more frequent communications and there is for sure some lower bound for the mean bandwidth we need. As I had a look at X11 today (a collegue needed to do some debugging on a remote Linux-box) I remembered this as very efficient way for remoting and this brought me to the idea of a XApplet.

XApplet is some Swing wrapper that can smoothly switch between an X11-terminal mode and native processing. This means that the client runs either as an ordinary Applet on the client or that it just provides some Terminal-facilities that exchanges tiny messages like key-strokes and mouse movements to an Applet running on the server. Perhaps the full client can have regions of terminal and native components (given they are sufficintly independent).

What is the benefit of a terminal-mode, you might ask? The terminal-mode can easily implement some “asynchronous”  behavior and the bandwidth usage is quite evenly distributed. Software like Citrix (and within some limits Window’s Remote Desktop) have proven to be well functioning remoting tools in low-bandwidth environments. When you think of a typical mobile application this approach is perhaps not so bad…