Now this is cool and dearly missing from the internet. A democratic alternative to the root DNS offered by ICANN.
http://www.opennic.unrated.net/
I’m getting sick and tried of these new root namespaces being dulled out by ICANN. I mean seriously? .jobs??? Thats the biggest joke I ever seen. ICANN doesn’t function correctly anymore. The power of the root DNS need to be switched over to a better working body. ARIN is getting on my nevers too with the IP allocations as well. RIPE seems to be more friendly then ARIN now days.
I love how OpenNIC’s website referes to anything ICANN as legacy, and OpenNIC is open to partnerships to run your own top level root. Might submit a proposal for a .mono root later and host it…. Maybe not… Cute thought though
I’ve been hacking on libmozembed all week. Complete with the tons of headaches and victories that go along with it.
I came up with a pretty cool model for doing reverse pinvoke in a massive fashion. Instead of creating a delegate around each method and then pass each one to the unmanaged layer one by one, I decided to go the route of creating a struct strictly full of delegates to hold all my callbacks. I marshal that struct on the unmanaged side to a struct full of function pointers. Because its a little tedious writing a new delegate around each function, I went one step further and wrote an interface that declares all the functions required for each off the callbacks and wrote a nice little static little function wrap any instance of that interface in each of the required delegates. It’s nice and clean if I don’t say so myself. 
I’m currently wrapping up a bunch of the interfaces in mozilla to give us full control in the managed layer over things instead of the wrapper automatically assuming the most generic implementation like I was doing before. I decided that this was the best route when I hit a few places in the code like the profile and window creator and some of the other services I have to create anyways. I’m even opening up some the basics so that when the xpcom stuff is ready, we should be able to integrate XPCOM layer with everything. (Mostly just opening up my XPCOM wrappers and providing a few functions to get my running instance of the core XPCOM services that I’ve already created for use by the XPCOM wrappers)
I’m really moving to the route of integrating XPCOM to supplement everything past the basics. I think it’s going to be the best solution in the end. I think I evolved through the entire thought process that the Mozilla and Java integrators went through over the past 6 years in just a little less then a month and came to a very similar conclusion in the very end. The greatest part is that we can do it better then Java could ever do because of limitations with JNI and in what Java can support itself. Mono has Reflection.Emit and compared to JNI, pinvoke rocks. Where Java has always had to generate a JNI stub for (up until the latest breaking code and very unstable code), we do not need to thanks to the magic of Reflection.Emit.
I’m completely avoiding any requirement on any bit of the XPCOM wrapping stuff to get the use the basics with the browser embedding. It’s just when you want to access things like the DOM, the printing interfaces, the spell checker, and the thousands and thousands of other goodies, will you need to use the XPCOM interfaces. When its done, everything should play well and while still manually handling the gecko embedding parts. It will also make things more stable and faster in the end when it comes to straight up gecko embedding. Maybe some day in the future (maybe next year or something) we can even just go right to XPCOM for doing everything.
Also in a high level respect, I noticed that I’m going through the exact same struggles that the Mozilla ActiveX control guys went through. They wrap Microsoft’s IE api as well. However where they have COM and only work on Win32, I’m wrapping it at the layer that tlb2asm eats it up. It’s a bit interesting to say the least.
Oh well. Back to work.