Python wrapper for PGP 8.0

I spent an hour this morning building Python wrapper for PGP 8.0 using SWIG.  PyPGPsdk invokes functions exported by PGPsdk[XX].dlls using Python.  I also have PyPGPsc and PyPGPclientLib modules for invoking PGPsc.dll and PGPclientLib.dll.  I haven't had a chance to bang heavily on it yet, but its useful already.

When and if PGP.com allows me, I'll release the work.  Yes, it is possible but I have not tried to generate Perl, PHP, Java, and C# wrappers using the same set of SWIG files.

RDF Syntax, Killer Apps, and Intellectual Diaphragm

Tim Bray goes further into RDF syntax problems to address issues raised in response to his recent post on the topic.  "Dave" thinks the problem is more serious than just syntax:

"But without a compelling app, or even better, a killer app, to pull it through, it doesn't matter what the format is….Anyway, I don't see any killer apps in the RDF crowd."Dave Winer

My position lies somewhere between Tim and Dave's positions.  Trying to build a killer app with RDF is somewhat like sculpting with Jello, difficult.  Still, I have been surprised many times in the past by what people can do with very little.

One lucky guy or gal out of millions of non-RDF gurus out there might have the right stuff to pull it off.  Trouble is, the RDF syntax is preventing RDF killerapps from being conceived like some intellectual diaphragm.

Daily Pointers

Daily Pointers is just that, brief pointers to interesting blog articles for that day.  Most of "Dave" blog entries are daily pointers, but I am not setup to do that.  So I'll bunch these little pointers into a single article updated throughout the day.  Let me know if this annoys you.

Ross Mayfield drew a simply wonderful diagram showing the Dynamics of a Blogsphere Story at a glance.

Tim Bray revisits history of RDF, spells out its problems, and issues a challenge.  It's a classic Tim Bray: nice and snappy.  Although I don't think his RPV syntax is much better than the RDF syntax, just marginally better, I enjoyed these comments:

  • The RDF version [of RSS] is harder to read, harder to write, and doesn't offer enough payback to make this worthwhile.
  • I don't know how to fix the no-killer-apps problem, but I'm pretty sure it's not worth trying until we fix the uglified-syntax problem.

The design of upcoming TypePad looks pretty nice.

<

p align=”center”>  

Refactoring to Patterns

      +  book cover=    ?

I have been studying and practicing design patterns ever since I ran across an early draft of GoF's Design Patterns book at Computer Literacy bookstore almost nine years ago.  I also enjoyed and continue to get mileage out of Martin Fowler's Refactoring book.  Today, thanks to ScottW, I found Joshua Kerievsky's Refactoring to Patterns, a growing body of work showing how to use design patterns in refactoring.  I suspect the work will continue to grow into an excellent book.  Read it now (750k PDF) and buy the book when its published.

BambooKit for Java Applet GUI

BambooKit packs a good looking responsive GUI toolkit into a 105K jar file that loads in less than a second (0.18 seconds on my laptop).  GUI is specified using XUL-like XML file, making it easy to change and without having to recompile Java code.  While its Look & Feel could use just a bit more polishing (visual quality is uneven across widgets), what you get is vast improvement over generic AWT.

BambooKit runs everywhere Java runs including handheld devices (its certainly small enough to fit into J2ME phones).  It is like a commercial version of Thinlet.  Go check out their online demo (look for the Demos tab which is implemented using BambooKit as well) .  You'll be impressed.

Cocoon Hell

Russell writes

"Well, I've spent the last week or so working with Cocoon and I give up. I can't get any real work done with it, so I'm moving on." – Russell Beattie via Marc Canter

<

p dir=”ltr”>Right on the ball.  I played around with Cocoon, but gave up on it eventually.  I find Java still good for server works, but found JSP and Struts to be inappropriate for a lot of applications.  I now discourage my clients from using Java if they don't have a significant Java resources already in place.  Dolts who read a few Java books and passed Java certification tests don't qualify as significant Java resources.  For most applications, going with PHP or Python will get you the same thing for a lot cheaper to create and evolve.  I am warming up to ASP.NET as well.

GraphViz and Technorati

While my son is watching Saturday morning flood of cartoon, I am playing with GraphViz, a neat tool for visualizing graphs.  Visio is nice, but it can be tedious and writing out complex structures in dot is much easier than the usual Visio routine.

Given its popularity, its lack of ready-to-use Python binding is weird (please don't mention Perl, I am allergic to it).  It should also support Flash and Visio output.  Still, a very cool tool and a joy to use.  I could sit here for hours generating pretty graphs.  Wouldn't it be really cool to hookup Technorati with GraphViz?  Wooo.  RDF and GraphViz also go really well together.

Emergent Markup Languages

Believe it or not, we live in a technologically backward civilization.  Everyday, hundreds of millions of people turn on their computer and enter a long sequence of characters into it, sequence which computers store, networks transport, and search engines index without understanding what they mean.

Markup languages such as XML can add meaning to those sequences of characters so computers can process them more intelligently, like differentiating prices from order numbers or Don Park from Donner Park.  But XML has, so far, failed to deliver on its promises.

Two great pitfalls of XML are:

  1. need for centralized control over creation and evolution of schemas
  2. high cost of developement, standardization, and education in time and resources

For some piece of data to be marked up, some one has to first define, document, publish, and publicize the schema.  After that the fun part starts: dealing with competing schemas and standardization process.  After standardization, millions of users have to learn how to use the new schema.  Whole lot of work and wait, for all parties involved, just to see a glimpse of XML Heaven.

What if we can skip all that?  What if people markuped content using their own names and structures, not those dictated by the central committee?  Will the resulting chaos be unsurmountable?  I believe not.  I believe that constraints and mechanisms inherent within human languages and social structures lead to what I call Emergent Markup Languages, common tags and structures that emerge from natural behaviors of individuals following simple rules like "call it what it is" and interacting with their immediate surroundings and neighbors.

Initially, Emergent Markup Languages will be most useful in marking-up salient parts of free-form textual content: phone numbers, addresses, numbers, names, etc.  Doing so will lead to abundance of fine-grained data we can harvest and process.  Its not quite Semantic Web yet, but we'll be much further along than before.