I guess in that early stage it seems OK. Compared to a JSR it probably is
no further than EDR stage right now.
Where say you have a particular state of the data set and either Java or JS
client, tagging them in a consistent way could make most sense. That was
the main reason for any tags other than /release you'd find.
Especially when there's something to demonstrate it is often a good idea.
On Wed, Aug 5, 2015 at 6:34 PM, Reza Naghibi <r...@naghibi.com> wrote:
> While your point is valid, it doesn't change the fact that a breaking
> change is being introduced into the specification.
>
> On Wed, Aug 5, 2015 at 12:28 PM, Werner Keil <werner.k...@gmail.com>
> wrote:
>
> > That's why occasional snapshots would also be nice here, even if they're
> > like javascript-client-2.0-alpha ;-)
> >
> > When ApacheCon is closer I'll have a look, but not yet.
> >
> > On Wed, Aug 5, 2015 at 6:25 PM, Reza Naghibi <re...@apache.org> wrote:
> >
> > > Small chance... but just incase someone is working or looking at the
> > > attribute spec, its going to change. Im currently putting together the
> > > javascript client [1] and given that JSON is a first class citizen of
> > > javascript, I want to make sure the JSON spec is perfect. Right now
> > > attributes are this:
> > >
> > > "attributes": [ { Attribute }, { Attribute }, ... ]
> > >
> > > This will change to this:
> > >
> > > "attributes":
> > > {
> > > "patternId_1": { Attribute },
> > > "patternId_2": { Attribute },
> > > ...
> > > }
> > >
> > > This will much optimize the structure for javascript and likely other
> > > clients.
> > >
> > > [1]
> > >
> https://svn.apache.org/repos/asf/devicemap/trunk/clients/2.0/javascript/
> > >
> >
>
