devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <reza.nagh...@yahoo.com.INVALID>
Subject Re: https://issues.apache.org/jira/browse/DMAP-112
Date Thu, 01 Jan 2015 17:16:36 GMT
Ok, just making sure.

So here is my rough roadmap:

-Jan 2015 - release data 1.0.2-Q2 2015, release data 1.0.3-Q3 to Q4, release data and client
2.0
      From: Werner Keil <werner.keil@gmail.com>
 To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com> 
 Sent: Thursday, January 1, 2015 12:05 PM
 Subject: Re: https://issues.apache.org/jira/browse/DMAP-112
   
That's why it is slated for a 1.0 release (regardless of maturity but it goes along with 1.x
of the data files) and it does not need to be compatible with any 2.0 data changes in future.Whether
or not we maintain 2 branches of data, guess time shall tell. Patches or fixes that can be
applied maybe, but like with other vendors (DeviceAtlas, 52DegreesMobi or ScienteMobile/WURFL)
they may not maintain 2 parallel repositories forever.
Werner


On Thu, Jan 1, 2015 at 6:02 PM, Reza Naghibi <reza.naghibi@yahoo.com.invalid> wrote:

I understand.

What is the roadmap for the legacy client?

Just so you are aware, 2.0 data release will remove the notion of a builder from the data.
How will the legacy client evolve to support this? Take a look at this:

http://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/simpleddr/src/main/java/org/apache/devicemap/simpleddr/builder/?pathrev=1648789


Go into the os, browser, and device. There is no way 2.0 data can maintain support for this
kind of builder architecture. Are you aware of this?

      From: Werner Keil <werner.keil@gmail.com>
 To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com>
 Sent: Thursday, January 1, 2015 11:48 AM
 Subject: Re: https://issues.apache.org/jira/browse/DMAP-112

Well, it's just a fact, the W3C Simple implementation shall be released as 1.0 according to
a discussion we had a long time ago.
It's been around and stable almost ever since OpenDDR donated it and that has not changed.The
only reason it was not released was an incompatible change (bug) you slipped into a Data release
1.x where packages of builders were named improperly.This was fixed with 1.0,1, thus nothing
prevents a release of the DDR artifact.
There is no rift, we have a .NET client (which is barely maintained, but that's another issue)
and a new direction which allows more flexibility in the "Cloud", e.g. retrrieving device
data from various sources. That's something W3C did not consider important, so the location
of the data source has to be fixed, that's the only real drawback of the W3C DDR implementation.
It could only be fixed in the W3C code we don't own;-)
I trust the PMC is wise enough to release the W3C DDR implementation, because not only examples
depend on it. And it provides functionality and recognition power the "New Cloud" client will
not get until V 2.0 as you also said. It does not matter if that happens in JIRA or the mailing
list, JIRA is also transparent and allows us to see what's been done;)
Cheers,Werner


On Thu, Jan 1, 2015 at 5:39 PM, Reza Naghibi <reza.naghibi@yahoo.com.invalid> wrote:

So I don't want to have discussions in JIRA, so Werner, can you please elaborate on your last
point in this thread:

"Indicates, while not in direct competition, the "older" W3C one is a bit more mature and
stable."
https://issues.apache.org/jira/browse/DMAP-112


The reason im asking you to elaborate is because as a PMC member, I would like to better understand
your thoughts on this project, its mission statement, and where we are going with our data
and API development.

Im concerned because you seem to be building a rift in this project in regard to old API vs
new API. This is not going to be good for the health of the project so this is an attempt
to better understand your views and feeling towards the project and the direction we are going
in. This is important because you are someone who actively promotes and markets this project.



   



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