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: [DISCUSS] SVN, versioning, and namespace
Date Mon, 20 Apr 2015 23:43:05 GMT
Actually though we did not make an effort to release the examples, if
you're really serious about W3C DDR support rather than viewing it as a
threat or competition, it just should not matter if you take implementation
A, B or C.

The test is totally implementation neutral, it imports nothing other than
the 2 DDR packages.
Thus with practically no major change a line like

 initializationProperties.load(context.getResourceAsStream("WEB-INF/classes/oddr.properties"));
        identificationService =
ServiceFactory.newService("org.apache.devicemap.simpleddr.DDRService",
initializationProperties.getProperty(DDRService.ODDR_VOCABULARY_IRI),

from one of the 2 DDR examples can be parameterized so that necessary
arguments are configured via say web.xml. And any truly compliant
implementation will work.
So does migration from vendors like DeviceAtlas, etc. if either the vendor
no longer supports their products, shuts it away (like WURFL) or went
bankrupt. It all happens, and there are plenty of vendors out there. They
don't care, whether "Reza wrote this", Werner, Bertrand or anybody else.

If it's W3C compliant it'll work and they could replace their existing DDR
with little or no code changes, see the 2-3 lines above.

Werner

On Tue, Apr 21, 2015 at 12:37 AM, Werner Keil <werner.keil@gmail.com> wrote:

> There is or at least should be an "exploded" data too btw.
> Unfortunately right now, the http://devicemap-vm.apache.org/data/
> contains 2 identical copies of the 1.0.1 data, while the 1.0.2 folder is
> empty and therefore would just result in errors if a client tried to use it.
>
> Whether you don't care about even the .NET client (which now uses this
> /latest) or others out there, you cannot force everyone to switch to
> something that as of now doesn't even exist. It's an empty structure, so
> without a proper migration tool it is not going to be of any value.
>
> Thus it makes sense to have at least a 1.x and (whenever that is ready)
> 2.x in such folder. The "download" section will always provide existing
> versions of data and so far published software artifacts.
>
> The wording like "my data" or "your branch" is pretty self-unveiling, it
> sounds like Golum in LOTY "My precious" where a proper attitude for an open
> source effort should be "our team". Data that's released is out there.
> After "your rogue changes" to 1.0.0 data broke it, both 1.0.1 and 1.0.2
> data are OK and so far the complete W3C DDR Simple implementation does not
> rely on an external URL or JAR, so if I was just interested in "My client"
> or "My data" that's set, but I also care about different environments and
> platforms that work so people have a choice (somewhere close to what
> commercial closed source vendors offer, or as good as the limited resources
> allow it here)
>
> I doubt the 1.0 "bridge" is really compatible with W3C DDR Simple, as it's
> not just about implementing an interface or two in that JAR.
> The official TCK for the W3C DDR Simple API is here:
> http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/java/src/test/.
> There's a copy of the test here, too:
> https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/simpleddr/src/test/java/
> It's not a JUnit or similar test though, check out the source and How the
> test bed calls it there. In theory the result of getReport() which is the
> essense of the tests could be put inside a JUnit tests running assertions
> against that result. The test itself is as provided by W3C, it must not be
> tweaked or "improved", that's how they tested several other implementations
> like DeviceAtlas, MaDDR and others before. If you get this test to pass
> then you may call the bridge around Classifier W3C compliant. It has
> nothing to do with "me accepting it", the test has to.
>
> Werner
>
> On Tue, Apr 21, 2015 at 12:00 AM, Reza Naghibi <rezan@apache.org> wrote:
>
>> So I will try and response to this as best as possible:
>>
>> -Browsermap has nothing to do with this.
>>
>> -There are 2 full W3C DDR solutions, ODDR and 1.x. If you dont accept the
>> 1.x W3C solution, so be it. Just another reason we need to split the repo
>> and releases since we are seeing this world differently.
>>
>>
>> https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/classifier_w3c_simple/
>>
>> -Your right about the namespace, everything does start with
>> org.apache.devicemap (for clients that support namespaces). My point is
>> that anything based on ODDR needs to have an ODDR tag in the namespace,
>> name, release name, release repo, whatever. It just needs to be named with
>> something unique to the client so it doesnt get confused with the 1.x Java
>> client.
>>
>> -Sorry, but just because im doing the data releases doesnt force me to
>> support your work or any number of clients. Anyone is free to maintain and
>> release their own data. I do it because no one else is doing it. I have 1
>> more 1.x data release planned and if it works with ODDR, great. It
>> probably
>> will. But once 2.x gets released, im not planning on releasing anymore XML
>> based ODDR data. You are more than welcome to backport the 2.x data to
>> ODDR
>> format and release however you wish. *Blocking my data work to support
>> your
>> branch is a non starter.*
>>
>> So im still not seeing whats the point of this argument. You are not
>> bringing any solutions to the table, just once again opposing me for the
>> sake of arguing. The proposal is that we partition our work into different
>> repos/releases/codebases. This was proposed by Bertrand, Radu is already
>> on
>> board. I am on board. Once I hear from Eberhard, thats pretty much enough
>> to move forward with something votable.
>>
>>
>> On Mon, Apr 20, 2015 at 4:52 PM, Werner Keil <werner.keil@gmail.com>
>> wrote:
>>
>> > Well I can only tell what works for BrowserMap and there is no reason to
>> > handle this differently here.
>> > there is no "2 products" and there is just one full W3C DDR
>> implementation
>> > (leaving the partial "classifier_w3c_simple" test balloon aside that I
>> > don't know whether you'll do anyting with this or not)
>> >
>> > Everything in the Devicemap project is supposed to start with
>> > "org.apache.devicemap" if you like to work outside that, Bertrand
>> outlined
>> > that before. Being responsible for the major portion of the data and a
>> > proper committer to proper artifacts, there is no reason to do any
>> > ridiculous "sandboxing" or defranchising of the W3C compliant artifacts
>> > just because some (or just one) in the team hate or don't undertand
>> them.
>> > It is as simple as every other project, be it Logging, Tomcat, all of
>> these
>> > have multiple streams of development that e.g. between Tomcat 6, 7 or 8
>> are
>> > totally isolated against each other.
>> >
>> > The CI servers grant proper stability. And just look at the current
>> single
>> > instance, the results show what's stable.
>> > Everyone, including yourself voted +1 of a strategy for W3C DDR, API you
>> > remember.
>> > This wasn't just for fun or to waste our times, it was meant to help any
>> > W3C DDR implementation. Doing so in a more isolated module sounds OK,
>> but
>> > that's about it.
>> > Who can help and fix say the bugs of the .NET client does so. It may
>> not be
>> > so widely used, but fixing the problem of the wrong data URL (directly
>> from
>> > SVN which at the time must have been the only place, so Eberhard isn't
>> > really to blame;-) helped to make the .NET consoles work. Maybe not
>> > everyone would have spotted it, not everyone also uses Visual Studio,
>> but
>> > what counts is working software that allows users to detect their
>> devices
>> > properly.
>> >
>> > That's how it looks and based on how Browsermap does this we could make
>> it
>> > work, but not some non-Apache pseudo world, if you understood it that
>> way,
>> > please check again.
>> >
>> > Cheers,
>> >
>> > Werner
>> >
>> > On Mon, Apr 20, 2015 at 10:17 PM, Reza Naghibi <rezan@apache.org>
>> wrote:
>> >
>> > > Werner,
>> > >
>> > > I believe your understanding of this is different that mine. Im saying
>> > this
>> > > as politely as possible, but my understanding is that you and me share
>> > > nothing moving forward. This includes code and releases.
>> > >
>> > > Since your focus is on ODDR, we move all ODDR artifacts to a separate
>> SVN
>> > > and you do whatever you want there. You do not touch or commit code to
>> > any
>> > > 1.x or 2.x SVN repo. This includes tags and branch. Even when you
>> > release,
>> > > you maintain that release in your ODDR repo. Its important that client
>> > > maintainers get isolation from rogue commits.
>> > >
>> > > So ODDR will have branched data and any future release of device data
>> > will
>> > > be done with no concern for ODDR. This is very important. 1.x now
>> > functions
>> > > independently of ODDR. Obviously 2.x will be completely different
>> > product.
>> > >
>> > > You can work on new code in /branches, but said code needs a vote for
>> > > anything to happen.
>> > >
>> > > The stipulation here is that you work under a different name space and
>> > > version. ODDR is an acceptable namespace string. We need to agree on
>> > > version.
>> > >
>> > > So, if we reach agreement and vote on this measure passes, from that
>> > point
>> > > forward, we should have zero interaction other than Apache required
>> > voting.
>> > >
>> > > Also, FYI, since 1.x and ODDR support W3C Simple DDR, you need to be
>> more
>> > > specific when you mention W3C since you are potentially talking about
>> 2
>> > > products.
>> > >
>> > > On Mon, Apr 20, 2015 at 3:19 PM, Werner Keil <werner.keil@gmail.com>
>> > > wrote:
>> > >
>> > > > Yes,
>> > > >
>> > > > Though they were not released there are nevertheless a number of
>> > > examples.
>> > > > All currently under the "org.apache.devicemap.examples" namespace
>> > (which
>> > > is
>> > > > what many projects do, Sling or DeltaSpike included)
>> > > > At leasts the 2 instances running on URLs like
>> > > > http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
>> > > > projects.
>> > > >
>> > > > Whether  or not there was a different structure, since they were not
>> > > > officially released yet, we seem free. I don't see great harm in the
>> > > > /tags/examples tag as mentioned. It marks a stable RC1 snapshot of
>> what
>> > > > could become a joint "examples-1.0.0" release. Unless we prefer to
>> > > further
>> > > > disect them, but that does not make a 1.0-RC1 worthless. It matches
>> > what
>> > > > runs on the VM for example;-)
>> > > >
>> > > > With few exceptions btw, the 0.x version space was for incubating
>> > > projects.
>> > > > Hence and since others like Browsermap (or the W3C impl) had a
>> longer
>> > > > history some version numbers were already higher before graduation.
>> > > >
>> > > > Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or
>> > Tamaya
>> > > > sounds worth exploring.
>> > > > This would be an area for 0.x kind of artifacts. And "playground".
>> I am
>> > > not
>> > > > sure, if it was a good idea to have an entire branch for that, but
>> open
>> > > to
>> > > > ideas.
>> > > > Earlier efforts like the Sling demo Radu worked on some while ago
>> could
>> > > be
>> > > > good in such "sandbox" (at JavaMoney we called it "shelter"
>> inspired by
>> > > the
>> > > > "Adopt-a-JSR" program and there's been some great progress in such
a
>> > > > sandbox, e.g. Groovy support, Digital Currencies, etc.)
>> > > >
>> > > > Werner
>> > > >
>> > > > On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <rezan@apache.org>
>> > wrote:
>> > > >
>> > > > > Also, as far as I am aware, we only have 4 officially released
>> > > artifacts:
>> > > > >
>> > > > > -data
>> > > > > -java client
>> > > > > -.NET client (its not on the website but im certain we did a
VOTE)
>> > > > > -browsermap (javascript) client
>> > > > >
>> > > > > All artifacts are all versioned in 1.x.
>> > > > >
>> > > > > On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <rezan@apache.org>
>> > > wrote:
>> > > > >
>> > > > > > Moving this to a clean thread.
>> > > > > >
>> > > > > > If we can reach agreement here, I will start a [VOTE] thread
>> with
>> > all
>> > > > the
>> > > > > > details listed out and upon a successful vote, we will implement
>> > said
>> > > > > > details (and enforce them moving forward).
>> > > > > >
>> > > > > > Feel free to add any points you think are relevant. As always,
>> > > refrain
>> > > > > > from using names, just technology and practices.
>> > > > > >
>> > > > > >
>> > > > > > On Mon, Apr 20, 2015 at 1:30 PM, Reza Naghibi <rezan@apache.org
>> >
>> > > > wrote:
>> > > > > >
>> > > > > >> Bertrand, PMC members, et al,
>> > > > > >>
>> > > > > >> So I had a few out of thread conversations with people
and it
>> > turns
>> > > > out
>> > > > > a
>> > > > > >> these people are very committed to DeviceMap and by
leaving
>> this
>> > > > > project I
>> > > > > >> would be kind of letting them down. This was never my
intention
>> > and
>> > > so
>> > > > > Im
>> > > > > >> willing to take Bertrands offer and apply some kind
of code
>> > > partition
>> > > > > >> policy.
>> > > > > >>
>> > > > > >> So here is what I would be willing to work with. I will
explain
>> > the
>> > > > > >> standard SVN layout with an addition to accommodate
the ODDR
>> > branch:
>> > > > > >>
>> > > > > >> https://svn.apache.org/viewvc/devicemap/
>> > > > > >>
>> > > > > >> *tags* - this folder is for Apache DeviceMap released
snapshots
>> > and
>> > > is
>> > > > > >> obviously used for archiving and branch sourcing purposes.
Any
>> > > > software
>> > > > > >> that is unreleased under Apache rules will be cleared
out.
>> > > > > >>
>> > > > > >> *branch* - this folder is open to anyone to work on
new
>> releases
>> > or
>> > > > > >> experimental features. Just make sure to put your code
in a
>> proper
>> > > sub
>> > > > > >> directory.
>> > > > > >>
>> > > > > >> *trunk* - this folder is only for development of currently
>> > released
>> > > > > >> software. If said software is unreleased, then it needs
to go
>> into
>> > > > > branch
>> > > > > >> or the ODDR folder. *This will require significant cleanup
>> since
>> > we
>> > > > have
>> > > > > >> the marriage of 1.x and ODDR in here. I repeat, unreleased
code
>> > and
>> > > > > their
>> > > > > >> dependencies, specifically ODDR will be moved into
>> > > > > >> their appropriate folders.* When we release a major
version,
>> the
>> > > > release
>> > > > > >> branch and move to trunk and the prior major version
will
>> switch
>> > to
>> > > > > branch
>> > > > > >> (and tags will be made). This way we can support old
and new
>> but
>> > > trunk
>> > > > > will
>> > > > > >> always be our release head.
>> > > > > >>
>> > > > > >> *oddr* - we need a separate repo to house ODDR artifacts.
>> Adding a
>> > > > > >> folder to our SVN root should be enough to accommodate
ODDR
>> dev.
>> > > > > >>
>> > > > > >> The other request I have is agreement on an ODDR name
space and
>> > > > > version. *Had
>> > > > > >> I anticipated this situation, our 1.x release would
be 2.x, the
>> > > > proposed
>> > > > > >> 2.x would be 3.x, and ODDR could hold the 1.x version.
This
>> was a
>> > > > > mistake
>> > > > > >> and that ship has sailed.* My concern is that I dont
want
>> > currently
>> > > > > >> released software to be up-revved in repositories and
cause
>> > package
>> > > > > >> confusion since we are all sharing the DeviceMap name
space.
>> So we
>> > > > need
>> > > > > to
>> > > > > >> properly name and version ODDR so if it does get released
and
>> > > > > maintained,
>> > > > > >> it can be done without causing confusion with regard
to the
>> 1.x,
>> > > 2.x,
>> > > > > 3.x
>> > > > > >> release path we seem to be going down. I would be willing
to
>> give
>> > > ODDR
>> > > > > the
>> > > > > >> 0.x version space since thats a pretty standard practice.
Im
>> open
>> > to
>> > > > > ideas
>> > > > > >> here.
>> > > > > >>
>> > > > > >> Since we dont really have the ability for grainular
folder
>> > access, I
>> > > > > >> think we have to ask that if you did not create or work
on a
>> > > > particular
>> > > > > >> code base, ask permission before committing otherwise
you can
>> > expect
>> > > > > your
>> > > > > >> code to be reverted by the maintainers.
>> > > > > >>
>> > > > > >> Finally, any sort of marketing or presentations must
clearly
>> state
>> > > the
>> > > > > >> product (codebase) and version as to not cause product
and
>> version
>> > > > > >> confusion.
>> > > > > >>
>> > > > > >> If we can all come to agreement here and then implement
the SVN
>> > > > changes,
>> > > > > >> then I would feel very comfortable that we can move
this
>> project
>> > > > > forward in
>> > > > > >> a more partitioned fashion.
>> > > > > >>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

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