Francois Orsini is working on JavaDB, a derivant of the Apache Derby RDBMS. In one of his recent articles he is talking about the possibility of using JavaDB for offline AJaX. This is - as far as I am concerned - a very promising step in the right direction: We all love the rich UI that AJaX can provide - the problem is only when we are offline, all those applications do not work anymore. By caching the various requests on the client and synchronizing them upon reconnect, you can make web applications into real applications. As Francois points out, this can be achieved by simply modifying the client side call behavior (check if connected -> synchronize -> use local copy).

I would have a whole bunch of applications that would be useful:

• Calendar
• Email
• Spreadsheet & Word Processing
• Bloging
  

Actually, with these four applications I could do about 60% of my work offline - as long as I have a browser that is AJaX and JavaDB enabled.

Seldom have I seen somebody less honest than Mike McCurry: His claim that the discussion around Net Neutrality is 'left' vs. 'center' and/or corporation bashing could not be much further from the truth. As many have already pointed out, Net Neutrality is about enabling markets and even more so, limiting the power that a fairly small oligolpoly (in some more rural areas even monopoly) has.

The barrier for entry into the high-speed internet provider market is quite high (next to getting your backbone going, you need to reach out to your customers, which you only really can if you get into some contractual relationship with the very few owners of the 'last mile'). If people like McCurry actually pretend that there is something like market dynamics (let alone be a free one) playing here they are either (i) dellusional or (ii) liers.

If there was real competition and the chance for new competitors to actually enter the market, I would be in full support of letting the market play it out. But this is simply not the case.

I am a big fan of electronic calendars: no paper to loose, you an copy the data anywhere, great integration with other electronic collaboration tools, etc. One of the problems I had with the Sun Calendar Srever so far was that it is really designed around being on-line all the time. It has a reasonable (but aging) web interface and that's pretty much it. There is really no good support for disconnected clients like a laptop.

Thunderbird (particularly with the Mozilla Calendar extension) on the other side has great potential to become a strong contender in the collaboration client business. Getting those two products to work together was something I was looking for in a long time.

Today, I found a small perl script by John Littell, that runs as a daemon and translates from WebDAV to the WCAP protocol that Sun Calendar Server uses.

So finally, I can use the Mozilla Calendar extension and read and write to my corporate SCS based calendar. The setup is almost trivial: you start the perl script, point your Mozilla Calendar to the daemon (e.g. http://localhost:7080/beuchelt/) and it will translate your client's WebDAV requests into WCAP commands. This is just awesome.

UPDATE: Ah, I forgot to mention this: this script also works with Apple's iCal client.

After J#, X# and some more abberations, Microsoft is now fiddeling with the idea of Script#. This is a code generation tool for JavaScript - you start with a C# class, run the ssc.exe compiler and get JavaScript from the C# source, instead of IL. He also has some integration with Visual Studio working at this point. The obvious target for Script# is the AJaX world.

I haven't quite made up my mind if I like this approach or not. It definitively seems intriguing for developers that do not (yet) have a solid understanding of UI-side development.

Ars Technica reports some good news on the net neutrality issue. At least there is now an alternative to the Communications Opportunity, Promotion and Enhancement Act proposal available. Some members of Congress seemed to have realised the importance of this measure (maybe those that subscribe to Vonage??)

So, I am deep in FIFI right now. There will be two presentations on the project in the next couple of weeks:

SunLabs Open House 2006
June 1-2, 2006, Sun Menlo Park Campus, Bldg. 16
Track: 6
Room: 1281
Title: Project FIFI
Abstract: Fast Infoset is a ITU-T/ISO standard for effricient XML encoding. It is available for Java through the JWSDP and the Java.Net open source project. FIFI provides an implementation on Microsoft's .NET platform.
Time: June 1, 2:30-3:00pm PST


Microsoft TechEd 2006
June 11-16, 2006, Boston Convention Center
Track: Connected Systems
Code: CON-TLC307
Title: Enterprise WebServices interoperability between .Net and Java using WCF and Sun's GlassFish
Abstract: Web Services matured to address enterprise needs.
Interoperability between Java and .Net on Secure, Reliable and Binary messaging is a reality. Come and see .Net and Java interoperating in a real world enterprise scenario using Microsoft's Windows Communication Foundation and Sun's GlassFish web services stacks
Time: Breakout 13, CON Theatre 2; Wed, 14 Jun, 2:00 - 3:15 (Eastern)

Here is a nice little tweak for Visual Studio 2005:

In a debug session with the default settings, you can only see "External Code" in the call stack for the Windows/.NET code base. If you go to Tools -> Options... -> Debugging -> General, and unselect "Enable Just My Code", you can then see the entire call stack.

There is one caveat however: if you enable this option, VS gets a lot dumber about stepping into your code, so you have to set breakpoints very extensively.

At this time, most of you have probably heard about the Web Services Interoperability Toolkit for Java (a.k.a. Project Tango), which enables maximal interoperability between the upcoming Windows Communication Foundation on .NET and the Java world. If not, go see http://wsit.dev.java.net/ ASAP.

WSIT will be tightly integrated with the Glassfish Sun Application Server, which also features full FastInoset support. In fact, Glassfish will - based on the HTTP header content type - automatically switch between text+xml and application/fastinfoset.

Now, with the WCF integration that FIFI will deliver, you will be able to configure an Indigo client at deploy time (or even after) to use the by far more efficient FI encoding. And this (re)configuration will only take a change in a single line in the .config file of that client (assuming that you are using a CustomBinding in the first place ).

So, at the end of the day, you can start you deployment of SOAP and RESTful Web Services with angle brackets and as soon as you need a more efficient encoding, you switch to FI by simply setting the right config parameter in the WCF client. Can it be less painful?

Finally, with a lot of help from sgen.exe and a number of very talented inidividuals, I got the complex types to work this morning. The biggest issue was the way WCF compares Strings:
Java does sttring interning, .NET does not do this by default (this is why (object) string1 == (object) string2 is without further consideration a bad idea). Within the XML serialization framework however, WCF uses a NameTable to "atomize" (i.e. intern) strings. The Reader must return interned versions of the name, localName, namespace, etc. or the string comparisons in the generated classes will fail. Here is a sample from the generated code:

while (Reader.NodeType != System.Xml.XmlNodeType.EndElement &&
        Reader.NodeType != System.Xml.XmlNodeType.None) {

    if (Reader.NodeType == System.Xml.XmlNodeType.Element) {
        if (!paramsRead[0] && ((object) Reader.LocalName ==  (object)id4_agedHelloResponse &&
                (object) Reader.NamespaceURI == (object)id2_Item)) {
            o.@agedHelloResponse = Read4_agedHelloResponse(false, true);
            paramsRead[0] = true;
        }
        else {
            UnknownNode((object)o, @":agedHelloResponse");
        }
    }
    else {
        UnknownNode((object)o, @":agedHelloResponse");
    }
}

After fixing the Properties on XmlFiReader, it can now deserialize complex objects, and - as such - also use doc/lit in addition to rpc.

Here are the slides for the BOF.

FIFI-BOF-2535.pdf (424.64 KB)

Well, I really do not have any big secrets to uncover, but I wanted to point you WCF developers to an extremely useful tool: sgen.exe.

In itself the tool is quite handy, since you can pre-generate and compile serialization code that would otherwise be generated and compiled by WCF during runtime. The cost for doing this (while only during startup) is quite significant, so using sgen.exe, you can avoid this penalty.

The by far best part of sgen.exe is, however, the '/keep' switch. If you turn this on, WCF keeps the source code for the custom IXmlSerializable implementation, and you can tweak, adjust or - in my case - debug - your serialization process.

There is the obvious question on why FastInfoset and - more importantly for me at this time - why on Indigo (WCF)?

A lot of customers - particularly in the financial industry - have expressed their concern about XML and its 'bloatiness': it is simply to verbose to be useful in 10M, 100M or even Gigabyte sized transactions. This makes a lot of sense and thus, FastInfoset (and similar efficent XML initiatives) were born out of this need.

Sun has been behind FastInfoset from its inception and the current JWSDP and the Glassfish application server fully support FI. It has been a clearly stated goal that we see FI as our strategic binary Infoset representation scheme and we would like to achieve ubiquity.

To achieve such ubiquity, it is mandatory to cover as much server and client platforms as possible. With FI being available for the Java platform - supported and open source - this goal is actually achievable. But in order to be truely successful, it is also necessary to enable non-Java platforms to exchange messages in FI. FIFI aims at just that: to enable FI processing for .NET 2.0 and FI message exchange for WCF.

Reminder: the FIFI BOF at JavaONE is tomorrow, May 17, at 9:30pm in Hall E.