DDR Queries etc

["eberhard speer jr." <se...@ducis.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

the DDR Query service announced earlier (Proposal for DDR Queries,
08/12) is online.

To tie in with Werner's earlier suggestions to get "a more lively
discussion" going :

REST/JSON services
==================
I haven't had, or rather made, the time yet to fully document the
service on the site, but it ties in with the REST/JSON services
mentioned by Werner.

The service doesn't really do anything 'exciting', yet.
It responds to a GET request, with the additional *Ddr-User-Agent*
header (!), with JSON serialized OpenDdr property-value pairs.
(I also have a version that responds using protobuf.)

Basically, I want to establish a standard method for such services
which can be used irrespective of the underlying DDR, platform or the
REST-services built on top of it.

My main concern was to get the user-agent string parameter out of the
URL because :
- - it's ugly
- - makes the URL/service hard to 'read'
- - and the wild collection of often weird characters that can occur in
a user-agent string, even when encoded, can cause problems in the URL
query string.

A C# implementation would look something like you see below and would
presumably best be implemented at the start of a user session so that
the response can be stored in a session cache for reference throughout
the session.
In .Net the global.asax Session_Start event handler would be the place
to do this; I'm sure other stacks offer similar opportunities.

// service URL
string serviceUrl = "http://www.ducis.net/Ddr";
// Response HTTP Status Code
int status = 0;
// Response JSON string
string jsonDictionary = "";
// DDR Request
WebRequest request = WebRequest.Create(serviceUrl);
// additional request header !
request.Headers.Add("Ddr-User-Agent", request.UserAgent);
// DDR Response
WebResponse response = request.GetResponse();
status = ((HttpWebResponse)response).StatusCode;
switch (status) {
    case 200:
        // success
        using (StreamReader reader =
                new StreamReader(response.GetResponseStream())) {
            jsonDictionary = reader.ReadToEnd();
        }
	// do something useful :
	// 1 - deserialize json string
	// 2 - store in session cache as dictionary/hashmap
	// 3 - ...
	break;
    case 204:
	// empty response : Ddr-User-Agent of unknown device
        // OR not a mobile device (!)
	break;
    case 400:
        // bad request : Ddr-User-Agent Http request header was missing
	break;		
    default:
        // oops		
	break;
}

You can also test the service using a tool like the cRest plugin for
Chrome. I have attached a screen-print of such a test fyi.
(You can get cRest here :
https://chrome.google.com/webstore/detail/crest-client/baedhhmoaooldchehjhlpppaieoglhml)

When the documentation is ready I plan to make this service available,
as-is, free, without registration etc. to any and all.

Flat files
==========
As some of you may know my Miri is basically a fork of the OpenDDR
project. My main objective there was to make the resolver(s)
independent from the underlying data-source. So Miri can load the
OpenDDR resources from the original XML, via an RDBMS (MS SQL,
MySQL,...),from Redis or any other data-provider that can be tied to
the data-interface of Miri.

The current online version uses 2 flat files which are little more
than the original OpenDDR XML resources but serialized to JSON.
(Actually, the XML is loaded in an SQL server, some sanity checks are
performed and queries extract data which is 'massaged' in
dictionaries/hashmaps which are then serialized to JSON and written to
the flat files.)

This greatly reduces the size of the resource files and it allows Miri
to load all the data in its cache on start-up *much* faster (average
load time : 430 ms) leaving the 'competition' far behind.

I'm also thinking of giving it a go using protobuf serialized resource
files -- yes, I've got this 'thing' with protobuf ;-)

To be clear
===========
Obviously, I'm not looking to 'sell' Miri here -- although I do hope
to get some 'commercial' millage out of its services elsewhere. I just
want to contribute ideas, techniques, technologies and lessons learned
from a live system and use that live system to implement and test some
of the ideas coming out of the, I hope, soon "lively discussion" here.

Looking forwards to you comments etc,

esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQyTOxAAoJEOxywXcFLKYcuSQIALZgGzEJuVhDrvkU4Oj90W49
Nd4InpNc520MOPLO5e2WAPM2EF5RCsOWS3UadBv+fBP+jMH9PHpw7wmDEo59B/ka
O+gqq9a4M+42nRiPYmUg+K86EVl/afTjtfZXbbSpmymo71FVspKOgKMBLT7KAo17
KgvCd5uUC9PHrJMLekSCzH9vaq1ACkPAUmArwDQUGHaLgOY86OlXAqFZrGIXMZkZ
bZubZZojB/8byhol7KJnNuwq4xazck6t4gGc3OiDf9Z7xiTS9OxOt+mpcsJddx3h
Sjlk7F7ImxhSzvLLruoBc/gLv+i6JMBP2KKrgHrjK3KEtzmQX0zexLaD0WhPKDc=
=aMyR
-----END PGP SIGNATURE-----