Technical Beef -

... they end up on the web.

Link: http://code.google.com/p/abstractcanvas/

How frustrating is it to have on hand a tool as good as GWT, and still see that all the graphics libraries are tied to the browser! Take for instance chart libraries, it should be obvious that we don't want just some server-side charting engine that can create PNG or PDF, but looks awfully static in the browser, and we don't want either some smart javascript library that looks great in the browser, but can't even create any of the PNG we need to build offline reports. Indeed, we need both.

As it appears there is no such a beast, here is my suggestion to developers using the GWT to create graphics: choose an abstract graphics API, make sure there is an implementation available on both server and client side, and use it to build the next version of your library. That's it. Don't waste your time coding for only one platform when you have at your disposal a technology that can target several ones.

I'm so frustrated with the current situation, that I wrote a proof-of-concept and an example of what should/could be done. Let me introduce you to the AbstractCanvas, a very simple java library that provides a single interface (mainly a subset of the HTML canvas and a few extra methods), and two implementations, one based on the incubator's GWTCanvas, and another one on the standard AWT (but Java2D-powered). There is one single interface to create the graphics, but one just needs to instanciate the AWT implementation to create server-side graphics, or instanciate the GWT implementation to access the client-side counterpart that can dynamically display its data.

As a sample, I also wrote a very simplistic charting engine based on it. Of course, the main point is that the graphics generated server-side are static, but the graphics on the browser are fully dynamic, with some of the bells and whistles one can legitimately expect from a javascript charting engine: using reflection, the engine applies animation and dynamic annotationc when the implementation supports a specific interface.

You can try the demo here

And the project is hosted at Google Code.

A few words on the HTML Canvas implementation: The GWTCanvas provided by the GWT Incubator has a serious limitation on the text drawing (which is actually an understatement to say that there is NO SUPPORT AT ALL for drawing text). There is not such a limitation in the current WHATWG (HTML 5) Canvas specification and in recent Gecko-based (1.9+) browsers, but as long as Microsoft has decided to ignore the HTML Canvas, we're stuck to the limited set of features that are common to all the browsing platforms.

Anyway, to bypass this limitation, I extended the interface to add a basic text support based on some HTML div absolutely positioned above the canvas (on AWT, there is no such a trick, of course). I tried to stick closely to the current HTML5 specs, so when the time comes where the full Canvas API is available on IE as well, it shouldn't be too much trouble to implement it using the standard methods. Or even, to provide another implementation when another solution, better than VML, is found for IE.

The AWT implementation was built on top of Java2D. That was rather easy, the Java2D API already provides everything needed to emulate the Canvas, and I'm pretty satisfied with it, as the resulting graphics are very close to the HTML Canvas implementation of the browsers (on IE, Gecko, and WebKit).

Some screenshots:

Display in the JAVA2D AWT implementation (in a Swing window)

Display in the GWT implementation (IE and Firefox)

Despite the fact that the approach taken is very simple (it took me a few days to write the AWT implementation as well as the charting engine), it works finely (just try the samples).

However, I still wonder if the HTML Canvas is the best approach for the problem: what about using a Flash implementation when the HTML Canvas is not available, instead of the VML-based implementation used by the current GWTCanvas ? The current limitations, namely the poor performance on IE, the lack of text drawing, and the bugged gradient support are really annoying, and a web-wide initiative from the javascript developers, targeting pragmatic solutions, rather than expecting a futuristic standard that would possibly get the approval of Microsoft, would be more than welcome (IMHO).

I'm so tired with all the dozens of singleton pattern tutorials poping up every day, it's like there is a world-wide never-ending contest of the worst singleton pattern introduction ever. But hey, if there is a contest, ain't I supposed to contribute, and optionally TO WIN?!

So here is it, and what's better than a Single(ton) image to describe the pattern:

Note also that just like in every other useless tutorial, I won't mention the double-check locking issue or why the pattern should be avoided now that IoC is widely spread.

Every now and then I stumble upon a framework or a program using this poor old UDP protocol, and I kind of feel the need to make a parody of a famous YouTube video, except that I'm not enough of a drama king to make a good film, so I can just chew my beef on this blog: Leave UDP Alone! Don't use it. UDP was a handy protocol to have, back in times when we were bashing some C code with our bare hands or building some cheesy ad hoc network protocol for our petty university projects, but it's not worth it anymore.

Let's recapitulate what's good and wrong, but mostly wrong, with UDP.

- It's a packet-oriented. Actually, there's more constraints than benefits in using a packet-oriented protocol: the size of the data is limited, and large data needs to be fragmented at the application level (but keep in mind that the packet itself is fragmented by the lower network layers anyway if it reaches the MTU). In other words, if you want to transmit data over the (65Kb) size barrier, you need to implement your own fragmenting protocol over UDP. You can also do something similar to the DNS protocol: send all your data below 65-Kb in a UDP packet, and switch to TCP when it's above. Right, there's nothing like developing and maintaining the same protocol twice, so it's always something to consider... NOT.

NOTE: let me clarify what I just said here in a provocative manner: there are really good reasons why the DNS is designed like that, and I would have done probably the same choices (I hope so). The interesting fact is that once it was clear that the data had to be sent over multiple packets, the DNS people did NOT decide to hack the protocol and implement fragmentation (and integrity control, and so on) over UDP, they just made the switch to TCP when UDP was not suited. That was a smart move (this is said shamelessly with the comfort of my 20/20 hindsight). However, cases such like this one are rare, and chances are you're safe to assume that your own protocol is NOT similar to DNS.

- It's fast. But it's fast, because it's lossy. Keep in mind that both UDP and TCP run with the same engine: IP. The only difference is that UDP sends single packets, while TCP sends several related packets of data, but also manages their flow, packs them for the destination application in the correct order (which may be rather different from the order of arrival), and checks the integrity of the data. All the things that you would have done, sooner or later, at the application level when using UDP. The speed penalty for TCP mainly comes from the connection stage: by the time that TCP has done its protocol handshake, UDP would have sent and received several packets of useful data. However, most applications do send more than a one-packet-size payload, and once the connection is established, the speed penalty becomes irrelevant (specially when considering the benefits of the communication reliability).

- It's simple. Yes, it is. But it's not simpler than TCP, so we can just drop this argument where it stands: nowhere.

Once you've established that the networking communication between your servers has to be RELIABLE and/or VERSATILE (in size, at least in its evolution), you've also established that you need TCP. Not UDP. Because if you stick on UDP, you'll have to rewrite a TCP layer just to implement reliability and packet fragmentation anyway.

So, when is it relevant to use UDP ? Use your instinct, but there are a few acceptable patterns:
- Your protocol works correctly even with occasional losses of packets, and won't need the emitter to re-send lost packets.
- The data you send is inherently fragmented, or is easily fragmented in smaller pieces
- You really really need multicast, because you have an important number of clients. A handful of servers talking to each other is definitely not an important number, and the drawback of not having reliability is a severe dead-end, and is not to be taken lightly. So be wise, stick to your real needs.

If your requirements fits all (or most of) those statements, UDP may be a good choice, as it will give a real speed boost (over TCP). Otherwise, please just don't. Not in 2008.