devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <>
Subject Re: Clients
Date Wed, 01 Apr 2015 21:15:44 GMT
I will say this, if PMC members in favor of the polyglot client/data
approach can lay out some kind of roadmap, that would be helpful in
understanding the path the PMC wishes to take this project. Otherwise, the
uncertainty around new clients springing up from the dead is just
unbearable and totally unacceptable (in my opinion). I think its fair to
ask people to explain what their future plans are, right?

So if you want... (im looking at you Werner and Bertrand), please lay out
what you see as your dev roadmap for the next year(s).

Radu, join in too, what are your plans for BrowserMap? Same to you Eberhard
with .NET? These clients were less of a concern because they were not Java,
but with 2.0, all of our previous releases will have some kind of new 2.0

Finally, a question for those who really wish to walk on the wild side...
who is driving your client requirements?

On Wed, Apr 1, 2015 at 4:30 PM, eberhard speer jr. <> wrote:

> 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.
> 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.
> 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...
> So, I too await Reza's return -- had to look up "holiday" tho ;)
> esjr
> Version: GnuPG v2.0.22 (MingW32)
> iQEcBAEBAgAGBQJVHFV0AAoJEOxywXcFLKYc88oH/A36up91ipM/Rc54nYIpEh0u
> Wd0+LjC7pdronUKYU2bOmN6xPSOCg2SpJDnYRjKjebk59w6NxLYPOiKR0aBAV6TG
> hZtIUw/1UTyQH+TmnP0T6cnt/i0ZttjdsRR8JJSeQiW+kylxZuLQ6/2JX3F8xM+b
> zOJouK4oZJIUuoE1aCodcifHjeRvllg8V8ly63jPqAWWXojRLlBwoFqp2PLUSS4+
> NMSVbIG04F/lcaTI+jFGgXT9vYfGIwK5u+OzdyOHAsr8q5w5wDtyTD+qATMgCLg=
> =ieOW

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