Archive for June, 2007

iPhone!!!

Friday, June 29th, 2007

I went and did it.. I waited in line 2 hours and got the last iPhone at the local Cingular/AT&T store. Over 200 people didn’t get one.

The line a was long too. It was insane. The cops asked a few people to leave that got a little crazy when they anounced they were out. Way to crazy… You can see a few picks on my flickr and possibly later tonight when I get it activated.

Amazing Mozilla

Wednesday, June 20th, 2007

First off, I have to praise “Shana” (Andreia Gaita) for working on my old Gecko based WebBrowser control for the 2.0 version of System.Windows.Forms. I had ideal goals, lots of hopes, and not enough time to spend working on it. I have a job and some what of a life, which that only leaves a few hours each day these days to dedicate to Mono (a common cry of many of us open source developers that are not privileged to be employed to work on this stuff full time).

The Mozilla guys did a really good job to make Gecko reusable, even though its not their primary goal. Still, there are still a lot of problems. Some of them are legacy issues that steam all the way back to the way XPCOM was designed and how old Netscape ran things (releasing binary SDKs to work with Netscape with only the static and public interfaces they were willing to support exposed). Since that time, the Mozilla products have been in a sort of flux with how things are done in the open source world and how Netscape used to do it with respect to how each product is built, packaged, and released on each operating system and distribution.

Netscape’s requirements were that they needed to be able to allow people to only specific components they wanted to be exposed and the members of those classes they wanted to be visible, and they needed a form of reflection and an interface system that could help people access and expose their classes from and to other languages like from external C++ libraries, Java, and Javascript (and then later Python, Ruby, and Perl). They were influenced by the design of COM (as was Ximian when they designed Bonobo), and decided to write an IDL compiler (like MSIDL) and even reused the libIDL used by Bonobo, and that is where the XPCOM standard came from. Rather then write two sets of header files (one public and one private), all the interfaces would have a IDL file for them describing their classes and Netscape would only release the ones that were frozen and stable in the SDK. In a perfect world this would be all you would need to dynamically call into XPCOM; unfortunately, the SDK has not been the primary focus of the Mozilla project and many of the needed interfaces to do anything useful for the past 7 years, have not been frozen, making it the SDK almost useless.

In the past, the only (supported?) way to embed Gecko was to fork the entire Mozilla tree and change their build setup to fit your needs and statically compile your own implementations into your own setup. This is far from being a very elegant solution. You end up taking on the entire Mozilla tree (thats 20 to 30mb of code IIRC), and Mozilla takes a very long time to compile (a few hours is not uncommon, which just about every Gentoo user knows that pretty well). The best way to handle it would be to dynamically link an existing Mozilla installation.

Then along came the concept of the GRE (or Gecko Runtime Environment). This idea was to use a common GRE runtime for all the Mozilla products that would be guaranty binary compatibleness between each major version. This idea never really worked to well (mostly because the SDK was useless) and was phased out in later Mozilla, Firefox, and Seamonkey releases.

A number of embedding libraries and solutions started popping up in the Mozilla tree, but all of them still required you to build the entire Mozilla tree just to build the wrapper or library for your language or toolkit to embed Mozilla. One successful solution in this arena was GtkMozEmbed. It is built by default in all Linux builds along side whichever product you where building, allowing you to embed Gecko by dynamically linking libgtkmozembed.so that was pretty much included in every released Mozilla project. This exploded and allowed projects like Galeon and Epiphany to be born. However GtkMozEmbed is very limited in its functionality and only works for GTK+ users. We also can’t simply fork GtkMozEmbed because it calls code that is only available internally in Mozilla, and so its not possible to use if you are building externally.

The only solution left is to go against the rule books and use “unfrozen” interfaces. It works but the only problem now is providing a solution that allows everyone to build the library in their setup against the SDK or using the funny developer packages in each distro (there is no official way to build a developer package for Mozilla products except for building the SDK, so just about each developer package is vastly different from the others).

Thats what the mozembed code does. It works by dynamically linking a XULRunner or Firefox setup you have installed. We build it against IDLs and headers we get from the Gecko SDK. The only downside is that since we are not using all “frozen” IDLs, there is a small chance the API could change in future versions, but I’m not really worried because it hardly ever does change and its easy to fix internally (its nothing like trying to maintain a module for the Linux kernel from version to version). What we do is add the missing IDL files that we need (taken from a later release of Mozilla that I built locally) to the IDLs that are included in the latest Gecko SDK and then generate header files from them to build against (You can see those extra “unfrozen” IDL files here in the SVN).

I love Mozilla and Firefox, but I understand why Apple choose to port KHTML and create webkit to build Safari, even when after they hired people from the Mozilla project to work on it. I’m curious to see what Alp and company do with the Cairo port of Webkit. Apperently the Apple release of Safari for Windows (by porting a few of Apple’s Core techonologies) set the Cairo port back a bit. It would be great if Apple would release all the Core* stuff as open source but I don’t think that is going to happen.