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: https://issues.apache.org/jira/browse/DMAP-112
Date Thu, 01 Jan 2015 18:47:58 GMT
It's not "a better alternative", it's merely a "more mature" (since around
for 2+ years) one in certain areas, while see the "Cloud" retrieval of data
from many different places that's something it'll never compete with the
Classifier.

There are so many different projects at Apache who one could see as
"competing", Tamaya just started incubating, but there's a "legacy" (as
many not just in the Tamaya Team may call it) project Apache Commons Config
which just got a brand new re-write to 2.0. The Commons Config project
won't drop everything because Tamaya was incubated.

Similar and often more diverse with UI frameworks like Struts, Shale,
Tapestry, OpenFaces, Wicket and god knows how many others are there still
actively maintained?;-)

Making sure, data 1.x is out as a mandatory prerequisite is probably the
only thing that kept the DDR Client from releasing a 1.0-incubating release
in March 2014;-)

The "Cloud" enabled Classifier will need more help than just 1 or 2 people
and I hope we all manage to improve it, but especially those who either
used OpenDDR or any W3C DDR compliant library by a vendor that may not
exist any more (MaDDR, Volantis and many others, not to  mention those
tricked or alianeted by WURFL maybe still using its Open Source version
long outdated;-) all of them can more easily start using  DeviceMap Simple
DDR. And once they require more, they can move to a new version of
Classifier or the new 2.0 data, but that is likely at least 9 months ahead.

As a migration path having an Apache project rather than OpenDDR 2.0 is
also easier from a licensing point of view to companies or other
organizations where licenses also are important;-)

Werner

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

> Good, this is what I wanted to know when I originally sent the email out.
> Now its more clear.
>
> I laid out my roadmap and im going to be completely focused on it this
> year. Remember, this is a data first project. Its in our charter.
>
> I am going to ask that you work with me and move forward as best as
> possible. This project is too young and small to be able to properly deal
> with so many competing goals. If you are unhappy with this, then I would
> ask that you step down from the PMC. Its going to be a lot easier for me to
> steward this project without your distractions.
>
> Obviously this project is a democratic process and if you feel its in the
> best interest to keep completing APIs, then thats going to be upto you and
> the PMC. I just ask that you stop promoting and marketing one over the
> other. I only get involved in these discussions in response to your
> statements. Otherwise, I moved forward from the legacy client back in 2011
> when I first engaged with OpenDDR project and wrote dClass. I really havent
> really looked back since. The fact that its 2015 and you are promoting the
> legacy client as a better alternative is just a bit concerning, thats all.
>
>       From: Werner Keil <werner.keil@gmail.com>
>  To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com>
>  Sent: Thursday, January 1, 2015 1:12 PM
>  Subject: Re: https://issues.apache.org/jira/browse/DMAP-112
>
> Since the DDR Simple client was contributed and accepted by Apache as
> initial part of DeviceMap there is no useful path to release it under
> OpenDDR.org.A majority of issues were related to e.g. the domain, well
> that's been abandoned.
> And see Volkan's request, the "new" DeviceMap Java client just like
> everything else (except data 1.x) was NEVER properly released under Maven
> either,
> Having a "new" client incompatible and broken under Java 8 (while the
> "legacy" initial donation which should have been released 2 years ago works
> perfectly fine under Java 8 or even 9;-) is a very big concern and does not
> make it look good or mature until such bugs are resolved.
> Everything that matters to the W3C DDR implementation is in Apache JIRA
> now, too, so any GitHub ticket or old site from 2012 are pretty much
> irrelevant.
> Bertrand/all,
> According tohttp://httpd.apache.org/dev/guidelines.html
> Release Plans (also what Reza sketched, that isn't more than an "intent"
> since there has been no vote on it so far;-) require Lazy majority (at
> least 3 x +1 and more +1 than -1) decides each issue in the release plan
> It's a bit hard to say for a very small PMC like this one, so what are
> your intentions in this case?
> The W3C DDR Simple client has and always had some advantages the "new"
> client may never get or at most in a 2.x release some time in 2016 or
> beyond.- Recognition of close enough devices based on the "confidence
> level", so while several of the tickets and UAs completely unrecognized by
> Classifier or at most saying "Generic Samsung Device" (with a 320x250
> screen or so;-O) DeviceMap W3C Simple DDR will return the best compatible
> device from such family, e.g. a known "Samsung T530" can be identified with
> important aspects like screen size, etc. based on existing "T520" or "T520"
> providing a better result than Classifier for screen layout, etc.- True OS
> Version thanks to a more specialized Builder system, where a factory
> default OS is outdated, it'll be substituted with the actual OS of this
> device.- Works on Java 8 without bugs or glitches as of now!
> Some of these won't be "rewritten" by Reza till Java 9 or even 10 comes
> out, so why defraud the community of a client that offers all that now and
> did so ever since early 2013 in fact.
> A negative vote on DeviceMap Simple DDR 1.0.0 would mean to gain the
> community to access these and not lose them (forever or a very long time)
> it had to be removed from DeviceMap and launched as OpenDDR Java Client
> 1.0.0.29 or rather 1.1.0 (or even 2.0 who cares;-) with dependency to
> Apache DeviceMap Data. Unless of course a majority here preferred all of
> device-data to be TAKEN DOWN immediately and moved to OpenDDR-data while
> the DeviceMap users will have to wait for a working 2,0 rewrite of data,
> too?;-O
> DeviceMap would immediately lose the quality stamp "W3C Compatible"
> because just having some "legacy crap" XML that was inspired by W3C DDR
> without implementing the W3C Simple DDR API does not mean any of that will
> ever be W3C compliant. It simply isn't, leaving that quality stamp to
> OpenDDR .next.
> WDYT?
> Werner
>
>
> On Thu, Jan 1, 2015 at 6:34 PM, Reza Naghibi
> <reza.naghibi@yahoo.com.invalid> wrote:
>
> >> Everything that's not under "contrib" should have at least one official
> release.
>
> Just to be clear, im going to be voting -1 on any legacy client release.
> The legacy client can be downloaded and supported here:
>
>
> https://github.com/OpenDDRdotORG/OpenDDR-Java
>
>
> The above project can be the branch you are talking about. I dont see any
> value or upside in re-releasing another legacy client branch under
> DeviceMap. Have any of the issues [0] been resolved? What about the pull
> requests [1]? Lots of reasons to move on from this client. Then we have the
> fact that 2.0 will render it obsolete.
>
> [0] https://github.com/OpenDDRdotORG/OpenDDR-Java/issues
> [1] https://github.com/OpenDDRdotORG/OpenDDR-Java/pulls
>
>
>       From: Werner Keil <werner.keil@gmail.com>
>  To: dev@devicemap.apache.org; Reza Naghibi <reza.naghibi@yahoo.com>
>  Sent: Thursday, January 1, 2015 12:25 PM
>  Subject: Re: https://issues.apache.org/jira/browse/DMAP-112
>
> Everything that's not under "contrib" should have at least one official
> release. That's why I suggested to move the "test-data" folder into
> /contrib (unless we agree it shall better be deleted from /trunk?)
>
>
> On Thu, Jan 1, 2015 at 6:23 PM, Werner Keil <werner.keil@gmail.com> wrote:
>
> OK thanks.
> DDR Simple 1.0.0 is ready for release pretty much as of now. A few minor
> improvements include using only Log4J 2 instead of SLF4J ("Eat your own
> Dogfood" at Apache if you want, all examples are already migrated;-) The
> only dependency is Data 1.0.1 or above, aside from the embedded W3C JAR.
> A combined Examples project 1.0.0 shall follow. Demonstrating all Java
> libraries.
> Ideally we should have Jenkins CI sessions for 1.x and later 2.x branches
> of all relevant artifacts, at least "Java" and "Examples". The Java 8
> glitch showed, we must have more than just Java 6 even if this is the
> minimal JVM version we support until further notice;-)
> Werner
> On Thu, Jan 1, 2015 at 6:16 PM, Reza Naghibi
> <reza.naghibi@yahoo.com.invalid> wrote:
>
> 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