devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Clients
Date Wed, 01 Apr 2015 20:52:08 GMT
Eberhard,

inline

On Wed, Apr 1, 2015 at 10:30 PM, eberhard speer jr. <seshat@ducis.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> If I understand correctly, I tend towards Reza's view.
> I too have been having some misgivings about the direction things are
> moving in : clients before data.
> Yes, the data is key and that highlights one issue : getting, storing
> and maintaining reliable data.
> Apart from that, somewhere along the line OpenDDR messed up the Aspect
> thing.
>

OpenDDR just picked up the pieces as the WURFL/OMA community left it. You
see it in single files like WURFL.xml.
https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/OperatingSystemDataSource.xml
is practically unused, but nobody prevented us and clients from using it.
I don't think
https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/BrowserDataSource.xml

is used by any clients either, and except for the DDR client the builder
file is also more abused than used as intended.
Every entry in
https://svn.apache.org/repos/asf/devicemap/trunk/data/device-data/src/main/resources/devicedata/DeviceDataSource.xml
from "open_db_modified" indicates, these entries were shaped and defined by
some OMA data sources, that's where they got messed up;-)

Unlike Werner I do not think that's just a question of untangling the
> current data. Like Reza -- if I understand correctly -- I think a
> "framework" not unlike OMA's UAProfiles, following the W3C standards
> is required -- by the way it seems to me that the W3C 'client' is just
> an [unfortunate] example of a client implementing the Vocabulary
> [Aspect/Attribute] and that the Vocabulary concepts developed are the
> meat of the standard, not the client.
>

Untangling is one measure, it doesn't have to stop there. It depends on who
is willing to help with it and how regularly those people really get a
chance to do so.

Note, a large portion of the WURFL/data related mess was driven by OMA in
the first place;-) If it did some work that is worth taking into
consideration, why not. The majority of its technologies (no real standards
though) or showcases circle around Device Management, especially for large
enterprise networks. Tracking and identifying a device is largely tied to
an individual handset and user, not just a devvice model


>
> On the .Net client : why try and force Java code and other conventions
> and practices on it ?
> Why burden it with stuff like log4net when anyone can wrap the minimal
> .Net client in anything they like and add logging IF they need it.
> I can imagine for debugging [use application log for that : faster,
> 'native', no dependencies] a log may be handy but otherwise it's
> ballast and dependencies. In the time it takes to log an even the
> client can parse, what 10, 100 user-agent strings...
>
>
If you refer to suggestions on JIRA, it's probably best to comment there
directly, avoiding a giant thread dealing with several things at once.

Unlike the Java clients there is no real example on the .NET side other
than the console. Whether integrating the client in say an ASP.net
solution, I guess you know if you want do provide something like that or
not.


> So, I too await Reza's return -- had to look up "holiday" tho ;)
>
>
>
Enjoy yours, too,
Werner


> esjr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJVHFV0AAoJEOxywXcFLKYc88oH/A36up91ipM/Rc54nYIpEh0u
> Wd0+LjC7pdronUKYU2bOmN6xPSOCg2SpJDnYRjKjebk59w6NxLYPOiKR0aBAV6TG
> HWyikxTt8QHlFHDiI9TUBifZWTzXhUmAdnrZWYDi+gtG0zZsoBlwAbjCCSMAkEUR
> hZtIUw/1UTyQH+TmnP0T6cnt/i0ZttjdsRR8JJSeQiW+kylxZuLQ6/2JX3F8xM+b
> zOJouK4oZJIUuoE1aCodcifHjeRvllg8V8ly63jPqAWWXojRLlBwoFqp2PLUSS4+
> NMSVbIG04F/lcaTI+jFGgXT9vYfGIwK5u+OzdyOHAsr8q5w5wDtyTD+qATMgCLg=
> =ieOW
> -----END PGP SIGNATURE-----
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message