Hi, It's more related to the question of Embedded Devices I raised earlier, but since Eberhard's thread was quite broad and not necessarily pinpointing the RESTful service alone, I thought I'd reply here with a question.
The Eclipse M2M IWG, mostly fuelled by IBM it seems brought up OMA-DM again, based on sources at DeveloperWorks over 7 years old[?] The last releases are also as of 2008 http://technical.openmobilealliance.org/technical/release_program/dm_v1_2.aspx (many links seem at least temporarily dead[?]) but then again, the W3C DDR standard working group also finished its work around the same time. OMA has been involved to some extent in DDR, too. Do any of you see possibly synergies in either way? Based on the little documentation there is it looks like DeviceMap/DDR or similar device repositories may help OMA-DM or similar device management efforts more than they could benefit from them. Until they scrapped it, Oracle Embedded SDK also seems to have offered WURFL for a slightly similar purpose, to assist Device Management by the SDK. Does anybody have an opinion or know about concrete demand? Thanks, Werner On Wed, Apr 24, 2013 at 8:57 PM, eberhard speer jr. <[email protected]>wrote: > -----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-----
