A quick post -
Web services are great right? Interfaces expressed in WSDL and any implementation can sit behind it, right? In theory – but most, if not all, implementations of web services are done in Java. Dims puts out the call to action in a blog post here, offering up a solution of PHP/Perl/Python language bindings to the Axis-C++ project.
Not much blogging recently due to professional (day job and night job) and personal commitments.
In Web Services News
Note that Axis2 Milestone 1 (M1) has been released at http://ws.apache.org/axis2.
In Content Repository News
A JAAS implementation has been commited for Apache Jackrabbit, which should provide a flexible, abstracted security api for connecting to JSR-170 repositories.
MSE Scrapple has a discussion and pointers to a discussion on Topic Maps, which I find intriguing. I plan on researching the topic more.
In-house News
Currently the majority of my time is being spent right now with implementing a reference implementation of uPortal at JHU, focusing on WSRP exposed JSR-168 portlets. The JHU uPortal team has achieved modest but signifigant progress as we march towards a demo in the next couple of weeks (mid-March timeframe). Portlets are being developed by different members of the team. The Library is focusing on providing a Hermes public interface portlet.
The night job is focusing on implementing a content repository API, upon which different widgets and applications can be built.
For kicks check out Magnolia (version 2.0 is the most recent). It is an open source CMS whose content repository is based on JSR 170. It seems to be very full featured; a lot of the technical details can be viewed on the Magnolia Wiki.
It relies on the Apache Jackrabbit implementation of JSR 170.
TSS has an article on the newly finalized draft of JSR 170.
From the JSR 170 JCP page:
The API should be a standard, implementation independent, way to access content bi-directionally on a granular level within a content repository. A Content Repository is a high-level information management system that is a superset of traditional data repositories. A content repository implements "content services" such as: author based versioning, full textual searching, fine grained access control, content categorization and content event monitoring. It is these "content services" that differentiate a Content Repository from a Data Repository.
Many of today's (web)applications are interacting with a content repository in various ways.
This API proposes that content repositories have a dedicated, standard way of interaction with applications that deal with content. This API will focus on transactional read/write access, binary content (stream operations), textual content, full-text searching, filtering, observation, versioning, handling of hard and soft structured content.
I’m excited about this… an api that is pretty fully featured but seems to be lightweight. We’ll see how the reference implementation works and if we can use it to manage content in various repositories.
Some discussion at scrapple on Google’s growing number of search boxes, and contrast that to Apple’s Sherlock which I think most Apple users are familiar with and enjoy at least as much as Google (all hearsay on my part I suppose).
Sherlock can present multiple search interfaces, and those interfaces can search drastically different things: airline tickets, restaurants, medline search (?), present different types of result sets and different window elements to sort and get at the data they want.
Does the Sherlock approach juxtapose the Google approach, or do I not understand completely what Google's approach is? And in fact are Google's and Sherlock's approach similar: clean, simple, easy to use, similar interfaces.
The integration of the Sakai Help Form (in jira here) and Jira is basically complete. Posting an issue to the form will create an issue in the SAKAISUPPORT project in Jira. The implementation isn’t without its warts, which will hopefully be resolved with a much improved RPC interface from Atlassian in version 3.1 of Jira and some additional coding by me. What is live now for Sakai is tagged as BETA_1 here in Subversion.
Originally the integration was done using the XMLHttpRequest object, a la GMail, but that proved to be too time consuming with all the different browser inconsistencies. That would have theoretically been prettier since the client could post rich XML directly to the Jira service. And people familiar with HTML could easily incorporate it into their pages without much help. In the end a custom (hey, did I mention warts?) servlet was created for the integration.
In order to publish the work to the community, and so the project doesn’t collapse under its own weight, the structure of the project is being re-tooled (including a much improved Ant build file) before further development takes place.
So I switched to using the BlogJet blog publisher. It works only under windows though, but it functions with many different blog providers. Unfortunatly it is not immediatly compatible with the current TikiWiki. So BlogJet allows me to publish right from the desktop w/o the browser.
Also, I downloaded RSSOwl, a very slick RSS/ATOM reader. It is project of the month on sourceforge. It imports and exports opml, so my sage rss reader exported my feed subscriptions and RSSOwl imported them gracefully. It is available on multiple platforms (it is written in java).
