Tuesday, September 12, 2006

Microsoft today announced their "Open Specifications Promise", essentially a non-assertion covenant for a huge chunk of WS-* protocols. This OSP means (as fas as I can tell - and I am NOT a lawyer ;-)) that people can start implementing WS-* specifications without having to fear any action from Microsoft, as long as they do not sue Microsoft over these specs - duh!

This is quite good news for a number of reasons:

  1. All existing implementations of WS-* technology are safe from any legal harassment from Microsoft. Not that they would do this necessarily, but this covenant gives peace of mind.
  2. Since pretty much all security specs are out, OSIS and Higgins are now in a much better position to implement a WCS compatible InfoCard selector.
  3. The best thing about this is the fundamental mindshift at Microsoft. A couple of years ago this would have been unthinkable. Now it is real. This is really major change in the way Microsoft deals with the open source community. It can be hoped that this OSP is just the beginning of a much more open discussion with Microsoft.

Tuesday, September 12, 2006 2:38:53 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, September 11, 2006

Thanks to the folks at blogs.sun.com, crossposting works for me (again). THe issue was that in the new 3.0 Roller deployment, all XMLRPC traffic was redirected to an HTTPS endpoint - which makes a lot of sense, but caused my client (dasBlog) to give up.

Hopefully, we will see ATOM based publishing soon ....

dasBlog" rel="tag">dasBlog

Monday, September 11, 2006 7:48:28 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1]  | 
Friday, September 08, 2006

Tom Clark brought a very interesting article on patents to my attention:

http://www.eweek.com/article2/0,1759,2013011,00.asp

This is really not to single out Microsoft - everybody in the technology field(s) is doing this kind of thing right now. But it is plain wrong: On the one side I do see legitimate needs for software and similar patents - but the current system is obviously so overwhemled that all kinds of nonsensical applications can make it through the process.

From personal experience: some time ago, I had a friend who was in deep trouble: he wrote some open source software to control toy trains. Open source software - nice. Well, some patent troll from Oregon contacted him and told him about a patent he was granted that was - allegedly - infringed by this OSS package. My friend got an invoice for $200,000. It turned out that tthe patent in question "covered" any  cross-process communication - as long as it was related to toy trains. This patent was actually granted in 2003 - about 35 years after the first DARPAnet cross-machine communications RFCs and more than 17 years after Marklin released their first digital control system for toy trains. Bottom line: the system *is* broken.

Friday, September 08, 2006 5:37:20 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Wednesday, August 30, 2006

Here is a very nice introduction to ontologies within the context of the semantic web and - in particular - OWL:

http://www.cs.man.ac.uk/~horrocks/ISWC2003/Tutorial/

Wednesday, August 30, 2006 4:23:49 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

Here is a suggestion for the dasBlog folks:

After our corporate blog host (http://blogs.sun.com/) was upgraded to Roller 3.0 (which - by the way - has a couple of really nice improvements), my cross-poring would no longer work. Since this is quite annoying is went to figure out why this is so. It turns out that the Roller folks (at least at Sun) were thinking ahead and made sure that all calls the XMLRPC endpoints get redirected to a protected HTTPS handler. Makes sense.

Unfortunately, this break the posting mechanism for dasBlog, as well as a lot of other blog clients out there. While the Roller admins are now fixing this, I came up with a small idea how to get dasBlog to post to HTTPS endpoints as well. Since it uses the Cook Computing XML-RPC library, this fix is actually very straight forward:

You will need to fix just a very few items:

  • The CrosspostSite class in the newtelligence.dasBlog.Runtime namespace. Here you should add a propety like String transportProtocoll = "http" or similar. Also the schema for the siteConfig file file to accomodate this additional attribute.
  • The UI to allow proper configuration (duh!).
  • The HandleCrosspost() method in newtelligence.dasBlog.Runtime.DasBlogDataServiceGFactory.BlogDataServiceXml.CrosspostJob. This UriBuilder should be reconfigured to something like:
    UriBuilder uriBuilder = new UriBuilder
                                    (ci.Site.transportProtocol,
                                     ci.Site.HostName,
                                     ci.Site.Port,
                                     ci.Site.Endpoint);
And this should be it.

Obviously, for the long run I would love to see an ATOM protocol based mechanism, but so far this is a dream (I guess?!). Here is the URL for the Bug I submitted on SF.NET.

dasBlog" rel="tag">dasBlog

Wednesday, August 30, 2006 4:08:24 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

Well, I finally bit the bullet and decided to update my production blog engine to the latest build. This will be a new adventure, since I am now really on some 'terra incognita': I am running on a beta platform, with unchecked code. Cool.

Part of this experience was to migrate away from CVS (at least for this project) to SVN. One of the reasons I was hangin on to CVS was the wonderful Tortoise CVS gui that makes versionb control usable even for people who do not love command lines of at least 120 chracters. Realizing that there is now a Tortoise client for SVN as well (here), the move was easy.

The next 'challenge' was to migrate my blog from a .NET 1.1 platform to 2.0 (since I definitively prefer VS.NET 2005 over the older versions, and also like some of the performance improvements in 2.0). Again, this was reasonably painless (almost like Java (tm) ;-)).

So now here I present dasBlog 1.9 on ASP.NET 2.0. Hope it does not break.

BTW: Many thanks to the entire dasBlog developer team! Great job.

Wednesday, August 30, 2006 9:00:37 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, August 28, 2006

Since I was recently going through my inventory of Javascript components to update a web site, I decided to link a few of the nicer ones here. They are not as integrated as the GWT or Microsoft Atlas, but - at times - still quite useful:

Tigra Menu

http://www.softcomplex.com/products/tigra_menu/

This is a nice, easy to configure JavaScript menu bar that works quite well across different browsers (with the notable exception of using absolute positioning, so IE and FireFox will *always* require some different handling).

There are a few more components ot SoftComplex - check also their 'Tigra Hints', 'Tigra Tree Menu', and some more of their components.

The basic edition is free - they have PRO components for money.

SynForce

http://www.netspinner.co.uk/synforce/html/synforce.html

This is a small validation library, that comes under LGPL.

Xin Calendar 2

http://www.yxscripts.com/xc2/index.html

Really nice JS calendar that is free, as long as you keep a link to yxscripts.com from your web site. REALLY nice and extremely configurable.


Monday, August 28, 2006 4:33:33 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Here are the architectural overview pages for Project Higgins and Project Bandit:

Higgins

Overview: http://spwiki.editme.com/HigginsIntroduction

Presentation: http://spwiki.editme.com/HigginsOverview2

Bandit

Architecture: http://www.bandit-project.org/index.php/Architecture_and_Design

Roadmap: http://www.bandit-project.org/index.php/Roadmap


Monday, August 28, 2006 9:09:06 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, August 25, 2006
Here is a little article on Persistent AJaX (P-AJaX) I will be publishing:

---

Persistent AJaX

Applications using Asynchronous JavaScript

There are a growing number of applications that use Asynchronous JavaScript with the XMLHttpRequest object to dynamically update the contents of the user interface. This style of application creation is commonly referred to as AjaX and it is used widely for web based applications. Typically these application can only be used while the client is connected to the internet, since they update the content of the user interface dynamically. A big benefit of AjaX applications is that they can present a very rich user interface and can be used across a large variety of platforms and browsers.

At the same time, it is possible to use similar techniques for creating dynamic applications that are hosted on a local machine and do not require a connection to a server. Such applications tend not to use the XMLHttpRequest object, since network connections are not used.

The boundary of connected and disconnected applications is usually not crossed: either an application requires a network connection or it does not. However, there are many applications that can operate in connected and in disconnected mode, such as email, calendar, etc. Users are usually online, but also take the application to places where network connections are not available and use them in an offline mode.

This paper describes a pattern to create AjaX applications that can be used in connected and in disconnected mode. Ideally, a Persistant AjaX (P-AJaX) application and its data could be stored on a portable mass storage device, such as a USB “thumb drive,” and taken to any computing platform whether connected or not.

Connection State Discovery

It is important to determine for an application whether it is connected to the server or not. This can be done very easily by sending an initial XMLHttpRequest synchronously and setting a boolean variable to online or offline:

var online = false;

function testState() {

req.onreadystatechange = testOnline;

req.open('GET', url, false);

req.send('');

}

function testOnline() {

if (req.readystate == 4) {

if(req.status == 200) {

online = true;

}

}

}

Persistence Technique

In order to be able to use the P-AJaX application on a disconnected computer, it has to locally cache at least some data it receives from the server while connected. This can be done is a variety of ways, e.g. through HTML browser cookies. A more powerful way to cache data is by using a JavaTM technology-based RDBMS system, as it has been described in [1].

There are some major drawbacks to these techniques: browser cookies are stored in installation specific parts of the file system and cannot easily be transferred from there to a USB drive. While the database table and the engine code for the Derby Java RDBMS can be stored anywhere, there is no guarantee that all platforms have a Java runtime installed, thus losing cross platform interoperability.

A simple way to store data in arbitrary locations is a flat file. Such files can contain XML, text or any other data that would be fit for use with a P-AJaX application. This can be easily achieved in Internet Explorer using the FileSystemObject:

var fso = new ActiveXObject('Scripting.FileSystemObject');

var f = fso.createTextFile("C:\\temp\\file.txt",true);

f.Write(time);

f.Close();

f = null;

The FileSystemObject is an ActiveX object and therefore only available on IE. For Firefox there exists the jslib library [2], which implements a similar file JavaScript API for file access.

Cache Updates

In order to allow offline updates to the application data, changed data should get flagged if it changes. This can be done by encapsulating the application data in an XML node and preceding this node with a 'dirty-flag' node. This should include a time stamp of the last write access to the data, like this:

<root>

<status changed=”1”>

Wed Aug 16 10:28:40 EDT 2006

</status>

<data>

...

</data>

</root>

[1] http://java.sun.com/developer/EJTechTips/2005/tt1122.html

[2] http://jslib.mozdev.org/

Friday, August 25, 2006 7:22:47 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, July 24, 2006

Here is a nice AJaX pattern:

In most samples that I have seen so far, a global XMLHttpRequest variable is declared, since you cannot pass variables to the action handler.

In this article, they show a nice pattern, where you declare an anonymous function that calls another named function which may accept parameters; like this:

    http_request.onreadystatechange = function(){
        do_the_thing(http_request);
    };

This is particularly useful if you need to send of multiple XHRs without being able to gurantee the order in which they return.

Thanks to Joan Morris DiMicco for finding this.

Monday, July 24, 2006 8:44:45 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Wednesday, July 19, 2006

I was setting up SQL Server 2005 client tools (which are in parts .NET based) and notced that as part of the installation process, the installer generates native images from the the .NET MSIL code. The benefits are obvious, but I was under the impression that Microsoft was - at least in the past - discouraging such deployment behavior.

Wednesday, July 19, 2006 2:39:46 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

Copyright by Gerald Beuchelt.