Good news on C02 Emissions

Obama's announcement, combined with China's recent pledge, is the first good news I've heard on climate change -- ever! Happy Thanksgiving!

Viterbi Maximum Liklihood Decoding

Last night I was following up on a hunch that the Viterbi Maximum Liklihood Decoding algorithm could have application for spell checking. I remembered this algorithm from a class I took at Carnegie Mellon called Digital Communications. I went back to the course book, and started reviewing the matter. I hadn't remembered this course book as standing out from others, but now I can really appreciate how well written it is. It has very clear treatment of the subject matter with well broken-out examples, that build throughout the topic. Sklar is a great writer, and he clearly loves the subject matter. I like his pithy conclusions at the end of each chapter. He has a flair for understatement:

"In the last decade, coding emphasis has been in the area of convolutional codes since in almost every application, convolutional codes outperform block codes for the same implementation complexity of the encoded-decoder. For satellite communications channels, forward error correction techniques can easily reduce the required SNR for specified error performance by 5 to 6dB. This coding gain can translated directly into an equivalent reduction in required satellite effective radiated power (EIRP), which consequently reduced satellite weight and cost."

After reviewing the Viterbi algorithm, I was curious about who this Viterbi guy was, anway. I'd also seen a chart in the Sklar book, attributed to the "Linkabit" corporation. Turns out Viterbi founded Linkabit, then later Qualcomm, an eventually donated $50 million to USC where the Viterbi school of engineering bears his name. Interesting story.

Oh, and it turns out the Viterbi algorithm does have applications to spell checking.

Order-invariant Path Parameters with JSR-311 JAX-RS and Jersey

When defining web service resource URLs, you may find yourself in the situation in which you want path parameters to be viable in any order. For example, shouldn't these two URL's both be accaptable, and point to the same resource?

.../person/firstname/geoff/lastname/hendrey
.../person/lastname/hendrey/firstname/geoff

I've found that the best way to do this is to creat a single resource class, in this case Person, and to define subresource locator methods for "firstname/{firstname}" and "lastname/{lastname}". The trick is to return "this" in your subresource locator method, which affectively turns the subresource locators into a means to setting instance fields on the Person instance.

So when we look in the "PersonResource" class, our subresource locator method for 'firstname' is:

@Path("/person")
public class PersonResource{
private String firstname;
private String lastname;

@Path("firstname/{firstname}") //subresource
public Person getSubResource(@PathParam("firstname") String fname){
this.firstname=fname; //set instance field on this resource
return this;
}

@Path("lastname/{lastname}") //subresource
public Person getSubResource(@PathParam("lastname") String lname){
this.lastname=lname; //set instance field on this resource
return this;
}
}
The locator method for lastname follows the same patter. And that's all there is to it! I have not found this pattern covered or described in any of the docs for Jersey, but I have found it indespensible.

Creating "alias" URLs for Jersey JAX-RS JSR-311 resources

In NextDB.net REST we are supporting two syntaxes for accessing resources. Let's call it a "fully qualified" resource, and a "shortcut" to the resource. For example, to view a table with its fully qualified URL, you can enter a URL in the format:

http://nextdb.net/nextdb/rest/home/{account}/db/{db}/tbl/{tbl}

for example: http://nextdb.net/nextdb/rest/home/geoff/db/testchars/tbl/lines

The "shortcut" URL would be: http://nextdb.net/nextdb/rest/{account}/{db}/{tbl}

for example http://nextdb.net/nextdb/rest/geoff/testchars/lines

There's a simple "trick" you can apply using JSR-311 to make your resource appear at two different URLs. First, start with your "fully qualified resource". For example, here is snippet:

@Path("/home/{account}/db/{db}/tbl/{tbl}")
public class TableResource extends AbstractSelectableResource{
@PathParam("account") protected String account;
@PathParam("db") protected String db;
@PathParam("tbl") protected String table;
...

Now, to make an "alias" or "shortcut" URL, just define a dummy class that extends the resource you want to make a shortcut to. The purpose of this class is simply to "mount" the resource on an additional URL. Be sure to include all the path parameters and their names must be identical.

@Path("/{account}/{db}/{tbl}")
public class ShortcutToTableResource extends TableResource{
//this class is intentionally empty
}

Now your resource will be available on both URLs!

Jamwiki

A few weeks ago I installed JamWiki to document the new NextDB REST features:

http://www.nextdb.net/wiki/en/REST

I wasted a lot of time on XWiki, which basically was bloated, didn't work well, and basically produces a constant stream of stack traces. JamWiki works really well, it's nice and clean.

New ideas for REST in NextDB.net

I've got some more stuff to work on with regard to REST. Here's a
peek:

support for relationships in REST URLs (calling them 'links')

...account/db/link/FRIENDSHIP/from/uname/john/to/uname/tom

The path parameters "from" and "to" describe the tail and the head of
the relationship, respectively. In other words, we can draw a
relationship as an arrow from one table to another table. This makes
'from' and 'to' the natural path parameters.

The REST URL above is equivalent to:

NAME=FIND_FRIEND;
ROW f1 FROM FRIEND;
ROW f2 FROM FRIEND;
f1 RELATED f2 VIA FRIENDSHIP;
WHERE(){
f1.uname='john' AND f2.uname='tom'

}

In the REST URL, you don't have to specify any constraint on the 'to'
side of the relationship. The following URL would retrieve *all* of
john's friends.

..account/db/link/FRIENDSHIP/from/uname/john

is equivalent to:

NAME=FIND_FRIEND;
ROW f1 FROM FRIEND;
ROW f2 FROM FRIEND;
f1 RELATED f2 VIA FRIENDSHIP;
WHERE(TEXT name1){
f1.uname=${name1}

}

You'll also be able to execute your named queries directly via rest:

.../account/db/query/FIND_FRIEND/name1/john

So it all will play nicely with existing queries you have already
defined, and new ones you may define in the future.

I also intend to support cookies. So let's say you wanted to log a
user in via https, and then securely transmit his password with each
subsequent REST URL using regular HTTP (not https). First the user
logs in via a secure (httpS) rest access to a query you named LOGIN.
So the password below would not be in the clear, since the form on the
HTML page would GET to an HTTPS url. The URL is constructed
dynamically by the form on submission:

https://nextdb.net/...db/query/LOGIN/uname/geoff/pwd/xxxxxxx;set-cookie

the 'set-cookie' matrix parameter tells nextdb to return a set-cookie
HTTP header with a value equal to cypher('xxxxxxxx'). I.e., nextdb
will encrypt the value that was sent in your request's REST URL,
wherever it finds ;set-cookie, and tell the browser to pass a cookie
named 'pwd' (in this example) with a value that is the encrypted
version of whatever is in the REST URL for the password in the pwd/
{password} path parameter. The set-cookie matrix parameter can occur
at any path segment in the URL, and would be applied to whatever path
parameter is described by the path segment.

from that point on you can use regular rest URLs and nextdb will
substitute into your URL the encrypted cookie value. So you can use
URL's like this in your application, for later actions that require a
user's password:

.../db/link/ACCOUNT_DETAILS/from/pwd/;get-cookie

The get-cookie matrix parameter int the URL allows an HTML page to be
designed with static URLs, into which nextdb will dynamically
substitute the URL path parameters with values sent by the browser as
cookies. It's a bit of a mind bender but this allows a site be
designed with static URLs. The only dynamic URL ever generated by the
app is the single login query that sets the pwd/{password} path
parameter.

so when nextdb receives the static URL above, it will first see that
the URL incudes a get-cookie matric paramter. NextDB will then look
for a cookie named 'pwd' sent by the browser (or other http client),
decrypt the cookie value, and place the value into the URL where it
finds the get-cookie matrix parameter:

.../db/link/ACCOUNT_DETAILS/from/pwd/xxxxxxxx/

The URL above is then equivalent to this NextQuery expression:

NAME=ACCOUNT_DETAILS;
ROW r1 FROM USER;
ROW r2 FROM ACCOUNT;
r1 RELATED r2 VIA MY_ACCOUNT;
WHERE(){
r1.pwd='xxxxxxxx'

}

The net effect of this new style of REST url for queries and relationship traversal is to vastly reduce the amount of code an applicaiton has to write, and hopefully to make nextdb accessible to HTML/front-end developers.

Native REST support in NextDB.net

I'm really stoked on using REST to access NextDB.net. I've setup a Wiki for NextDB.net and here is our REST wiki page: http://www.nextdb.net/wiki/en/REST


Beeing down with a bad cold the last few days, ironically this has given me
some time to work with Jen from Dartmouth Design on using the REST features
to build some features for Project Have Hope. She has graciously offered to
share the preliminary results. So far we've used nextdb for creating
profiles of children to sponsor. The entire page, including the paging
links, profile data, and paypal buttons, is created by applying an XSLT
transformation to the table served up by nextdb. The result is sourced in an
iframe and loaded into a Joomla module. This appears to be a very nice way
to integrate nextdb content with Joomla. I'm also very stoked to see NextDB
used on such a worthy project.




You can read about the XSLT approach here:

http://www.nextdb.net/wiki/en/REST#XSLT_(reformatting_your_data%27s_presentation

This is the XSLT that is being used by Project Have Hope.
http://nextdb.net/nextdb/rest/dd/phh/config_files/row/1/xslt.xslt

I've just learned XSLT so I think there are many things that can be done
smarter, and there is also a bit of cruft template in the XSLT that is never
used (for example the 'append-pad' template is never used) and needs to be
cleaned up. But that aside, it's an amazingly small amount of XSLT
considering this XSLT is the *only* code required to bring together this
dynamic page.