-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here's a description of the existing code/functionality of a 'fork' of
the OpenDDR code I created and which I want to contribute to the
DeviceMap project.
I called the project Miri (yes, Star Trek) and below I use the
project's namespace to refer to the various components, a detail that
will have to change in due course.
Some design requirements I set :
- - CLS-compliance (ECMA-335) : standards are debatable, the point is
pick a sensible one and stick to it.
- - dependencies : avoid.
- - use technology available 'everywhere' : I use MS SQL but I'd put as
much trust in PostgreSQL (can't say that about MySql) and HTTP, Redis,
JSON, protobuf, exist 'everywhere' open and free.
- - the system should be used :
- to import known data sources (OpenDDR XML and UAProfiles)
- to export/serialize data sets used by the main device resolver
- to maintain Vocabulary/Aspect/Property definitions
- to maintain device data (with version control)
- to function as a main device resolver :
- API
- web front-end (editor rights for proper logons)
- to 'import' and analyze traffic log data (w3c and other log formats)
(this includes the log of its own API and web-front end !)
- the resolver functionality should be able to run independently
- - standards (repeat 3x) : implement, accommodate, all relevant standards
- - fun
Status : I've got the basics (resolver, api, logon, membership
rights,...) running in a flat UI on .Net MVC 4, 'release' ready and am
fiddling with HTML/CSS/MVC etc to get the other functionality in a
presentable and usable UI, a 'simple' matter of piecing things
together and it's ready for use/users.
Since I understand Reza is leading what looks like a very similar
effort, albeit on a different 'platform', I held back a bit not
wanting to seem to run interference with 'my' .Net stuff.
Miri namespace and functionality overview
============================================
Miri.Ddr : identical in functionality etc to OpenDDR's W3c.Ddr-Simple
Miri.Oddr : identical in functionality to OpenDDR's Builders and Models
main difference : no XML : uses IConnection :
interface to connect builders to data source
(dictionaries/hashmaps)
=> read from one source - write to other 'source'
OpenDDR XML -> SQL
UAProfile RDF -> SQL
SQL -> Redis (JSON/protobuf)
SQL -> JSON/protobuf (file, stream)
JSON/protobuf -> JSON/protobuf/*HTML*/...
... -> ...
Rather than parsing/loading XML in a cache, the main
device resolver loads a cache of 'pre-cooked' data.
The cache consists of builder-tokens and device-properties
key value pairs.
Miri : Main Device Resolver
- implements IConnection to Repository which is :
- a Db : holds data connection parameters read for config file
- a Version : holds version info on current Db and Resolver
- implements 2 resolution functions that take
Oddr.Models.UserAgent as parameter :
- Identify : returns a device Id (string)
- Resolve : returns an Oddr.Models.BuildObject (IBuildObject)
!! Because of the way the data is serialized in JSON
or protobuf the properties dictionary/hashmap contains :
name, value, aspect, datatype, description, default value
- implements logging for performance, debugging and testing
Miri.Parsers : - UAProfile parser
- fall-back parsers in case ua 'is not a device'
- Catfish response parser (see below)
Miri.Objects : Implements CRUD and query functionality (SQL) :
- Vocabulary/Aspects/Properties
- Device data : OpenDdr/DeviceMap & UAProfile (linked)
- UserAgent test data and test results
- data version control (device data)
- list devices per vendor, models per vendor,...
- list devices with property or property set...
- compare test data and results to device data
(develop 'calibrated' test data sets and tests)
Miri.Services : - Resolver Node : implements main device resolver
- API service : returns serialized IBuildObject
(JSON key value pairs)
- 'font-end' service : returns "Device"
- Device : implements and extends
W3c.Ddr.Simple.IService
- deserialize IBuildObject.Properties
- filter : returns property subsets from properties
- serialize : HTML, JSON, Protobuf
- data editor extension
Catfish : Catfish is a 'client-probe' javascript based on EFF's
Panopticlick and has been extended to include among other things :
dual-orientation, WebGL-spex,...
Included on '1st contact', it uses AJAX to return a JSON object with
useragent properties that can (partially) be mapped to device map and
uaprofile properties.
This 'response' can be used as fall-back or can used or stored for
analyses.
Data model
==========
The database contains : device data, vocabulary data and Useragent
test data. These 3 'sets' are interconnected.
Device Data : 'bulk' procedure import from OpenDDR XML or UAProfile
source files. This set of tables is only loosely normalized. Importing
raw data into a 'scratch' table and then using SQL to validate and
distribute the data over its respective final tables often proves much
faster and much less code/errors.
Vocabulary Data : strictly normalized tables following the W3C
Vocabulary/Aspect/Property model. Used in the validation of Device
data imports and to maintain 'authoritative' name, description, data
type etc. (OpenDDR/DeviceMap and UAProfile)
UserAgent Data : set of table with useragent strings, user agent types
and resolver tests and test results.
Looking forward to your suggestions as to which direction to run with
all this -- after digesting the above,
Regards,
esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJReA8VAAoJEOxywXcFLKYcGUIIAMTbfJhGQVTIA2Rur1ZDP5ws
9g8CQEOCd6WdPiSDkgPXrc9zyFDzT5cLcQxrnRGRHQu32zyRmMF5FhbZoDIFz5va
rmLJSqyBUNRbi2+TXNbvNAR/vPAF6MVymhLbWKbm0Iv/ELhrMjvLf386YBxZjVpi
LP8y/qqf5OAtZkypkfAri1IR0Gga4d04gAXP/1oISh3k6XoiToKnide2yUUm1PLR
HND1Z9pMMYUjPgHLy3nuQ4DFG9K5CvmztiLlNI8io9bJBzA6iJ+LbKyXUWsVgewO
OvbQdZD98hbmr4sf7PkMSY9Hul/N5h3gFQUsdtDv/aw74EgmKQ8QL3Xa5enqA5M=
=+Jhj
-----END PGP SIGNATURE-----
