This morning, I received PGP SDK 3.02 by Fedex from PGP.com.  I was expecting download instructions, so it was a surprise of sort.  A nice looking golden CD containing one 10mb Zip file.  Hmm.  I really appreciate the jesture, but this feels like a waste of money and resource.  Anyway, I'll be looking at it over this weekend.  Just now, I am having too much 'fun' with XSD.EXE.  If you know .NET, you know what I am talking about.

Struts is a popular open source Java library from Jakarta Project, a subgroup of Apache Software Foundation.  Its popular enough that seven books have been written about it so far and knowledge of Struts is a common requirement for Java web application programmers.  Docuverse website was written using a beta version of Struts.  Its the beta part that annoys me.  Struts 1.1 has been in beta for over a year now.  Because Struts 1.1 has signficant advantages over 1.0.x, most of my collegues have been using beta versions of Struts 1.1.  Here is the history of Struts releases:

2001 Feb 23 – Struts 1.0-b1
2001 May 19 – Struts 1.0-b2
2001 Jun 02 – Struts 1.0-b3
2001 Jun 15 – Struts 1.0
2001 Nov 27 – Struts 1.0.1-rc1
2002 Feb 11 – Struts 1.0.2
2002 Mar 19 – Struts 1.1-b1
2002 Aug 12 – Struts 1.1-b2
2002 Dec 31 – Struts 1.1-b3
2002 Feb 23 – Struts 1.1-rc1

Now there is rumor of impending 1.1-rc2 release.  *sigh*  Struts team should do thousands of Java programmers a favor by switching to a different version number scheme like 1.1.{build#}.  If not, the animal on the cover of O'Reilly's Struts book should be changed from a strutting horse to a Sloth, world's slowest mammal.

Everyone is talking about web services and web service choreography, but only one company is actually doing it: Collaxa.  Yes, IBM has a toolkit of sort, but it is prototype quality IMHO and just an engine too boot, leaving you to build and integrate rest of the beast.  BEA was smart enough to recognize this and written an eye popping tutorial using Collaxa's tools.  Go check out what Collaxa lets you do without a lot of XML and Web Services hassle.  You just know this is what everyone else is trying to mimic right now.

I am waiting for PGP.com to send me the SDK before moving forward.  While I developed the plugin without the SDK, I want to read the SDK docs to make sure I am not calling any private APIs and using PGP as intended by PGP.com folks.

Mark O'Neill mentions two examples of security vulnerabilities in XML software.  In summary, keep these two warnings in mind:

• Beware of URI – XML-based data formats are rarely standalone, meaning they rely on some external resources (i.e. DTD, fragments, images, hyperlinks) via URIs.  Blindly dereferencing or copying these URIs could result in a host of problems, most common being denial-of-service and cross-site-scripting attacks.
• Beware of Opaque Data – many XML-based data formats have elements or attributes whose values are opaque to all but few of system components.  SQL statements used in Mark's post is a good example.  Other components blindly pass on and store these values until it reaches components that can process those value.

Both URIs and opaque data are common ingredients of extensible systems.  Extensibility is good, but always remember that it is a double-edged sword.

PGP Corporation released PGP SDK 3.0.2.  Woohoo!  Two types of licenses are available:

• Weak-Link License – for developers who wish to take advantage of PGP capabilities on systems that already have a PGP product installed.  PGP libraries cannot ship with your product. This license is cost free.
• OEM Developer License - for developers who want to integrate PGP technologies into their products' feature set.  PGP libraries can be shipped with your product.  This license is not free.

To get the SDK, follow the instruction on the SDK page.

Collaxa's BPEL 1.1 Q&A sheet.  Don't forget to checkout an eye-popping demo of Collaxa's Visual BPEL Wizard.

Chandler 0.1 – Chandler is Mitch Kapor's open source Its-Not-An-Outlook-Killer written using Python.  This is the first release.  Here is what Mitch has to say about the release.

"The first release of Chandler, release 0.1 is now available! While we're still very early in the design and implementation process, we intend for this 0.1 release to make us a more fully open project. We have made the release available for download, opened up our bug tracking database, and opened our source code repository. We have also spent quite a bit of time in the past few weeks focusing on improving our code and documentation." – Mitch Kapor's Weblog

Twisted 1.0.4 – Twisted is a python framework for network applications.  This version features a few optimizations, drastically less buggy GUI reactors, fixes for several Perspective Broker bugs, a bit more documentation, and the customary extra helping of internet carries a hint of Washington D.C. cherry-blossom scent.

Lupy 0.1.3a – Lupy is a port of Lucene from Java to Python.  This version fixes a few bugs and adds Unicode related changes.

Since the bubble burst, contents have been disappearing.  Just yesterday, I have been reading some papers on techniques for simulating hand-drawings (I wanted to follow up on on my idea that UI artifacts like buttons that looks hand-drawn stands out, without being too loud, a very useful quality).  After finding and reading about ten interesting papers on the topic, I started reading secondary papers referenced in those papers.  What surprised me was that majority of those links were broken.  Mostly sites were simply shutdown.  Rest of them were due to papers being removed or moved elsewhere.

If I have some web resources that links to external web resources, only think I can legally do now is pray.  If the resources are critical to me, I can use a local copy, but there are several problems with using a local copy:

1. using a local copy may be illegal.
2. updating local copy is cumbersome and often requires manual review (real paper might get replaced with sorry-but-its-gone page).
3. UI may become confusing or verbose enough to interfere with the content.

Owners of those external resources also have their own problems.  First, they don't know who are depending on their resources, so there isn't much choice when they have to stop operation for one reason or another.  Second, scalability often cost too much and takes too much time to increase (when your server goes down because you got slashdotted, its too late to get additional servers).

One solution for both parties is to use web services to negotiate auto-mirroring of contents.  For external resource referencing sites (well, everyone), auto-mirroring guarantees that external resources referenced by their content will be available.  For owners of external resources, they can route requests to mirror sites when load gets too heavy.

Technically, its just mundane stuff.  Resource consuming server asks resource owner, via SOAP, whether certain resources can be mirrored.  If not, nothing is done.  If allowed, content is mirrored and resource owner notes the mirror location as well as information (capacity, location, etc.) useful for balancing load across multiple mirrors.

What excites me is that amount of work involved is relatively small, yet benefits are so huge.  I can easily imagine this being a standard web server feature within a year.