Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
Received-SPF: pass (nike.apache.org: domain of rezmang@yahoo.com designates
 72.30.239.79 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com;
	b=pEXuAONfQMrWc146Ze70f03JUg2qjkQcGhnn/XnZjvRTBV24XNbTNK08UiLGgLk/0Y3EfEOsa0CtEWiwg1cvJWa536/1jFKCusLjzTDngV6F2+ptV+WwBZhGM4fUu/O80xDl+XHG0yMydhhR4M2UCLg0D10ITnjxF83+ozLFc+heG22vF0uizS0AWjCkBu09JOA8dw9RH+Frgrx4tOWunYkFTRx0O33gLcby/L8QX/KI7BiEVjyAxfr9XpycYU6ISlS5l5LSuoeo28pS/zZeCBC2v0zpF/qC2Mr/jbhwYzJjF1G5nr8m5utCULmTFMJvRsYZqdjmMw8mqw36ABVg+Q==;
Date: Wed, 31 Dec 2014 13:38:31 +0000 (UTC)
From: Reza Naghibi <reza.naghibi@yahoo.com.INVALID>
Reply-To: Reza Naghibi <reza.naghibi@yahoo.com>
To: "dev@devicemap.apache.org" <dev@devicemap.apache.org>
Message-ID: 
 <586467830.3072835.1420033111934.JavaMail.yahoo@jws10673.mail.bf1.yahoo.com>
In-Reply-To: 
 <CAP7pH7sJma-+gp2Rr=hnrbcs8PqM6rY39vTOwgPDfKgjqOsh2Q@mail.gmail.com>
References: 
 <CAP7pH7sJma-+gp2Rr=hnrbcs8PqM6rY39vTOwgPDfKgjqOsh2Q@mail.gmail.com>
Subject: Re: JSON toString methods in data classes
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3072834_461289202.1420033111923"

------=_Part_3072834_461289202.1420033111923
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So I sent this email out yesterday, it never made it. So here it is again.

-Can we nail down the use case here with specifics? Everything mentioned be=
low is vague and generic. This is bad for feature development.

-Mission creep. This project is data first, api second. A presentation form=
atter is way out of scope. Effort is better spent on the data.

So regarding removing JSON altogether, ok, but we need to rethink our examp=
les then. Please see my previous point regarding mission creep. While I thi=
nk its good we are putting a lot of focus on the Java client, iterations ar=
e much needed on the data.

      From: Volkan Yaz=C4=B1c=C4=B1 <volkan.yazici@gmail.com>
 To: "dev@devicemap.apache.org" <dev@devicemap.apache.org>=20
 Sent: Wednesday, December 31, 2014 5:38 AM
 Subject: Re: JSON toString methods in data classes
  =20
My take on the issue is as follows:
1) Console example was already in a messy form and addressed in DMAP-54.
2) It is not client's responsibility to ship the functionality to format De=
vice/DeviceType/Map<String,String> for JSON/XML. Java client -- as its name=
 implies -- after all is just a client and it should behave like one so.
3) Servlets... I really could not understand what a servlet example has to =
do in a UserAgent-to-DeviceAttributes library. Anyway... I will address thi=
s issue in a separate thread.
In the attachment, you can find the following two patches: 1) Remove JsonPa=
rser from Java client and 2) improve servlet example. Since I still could n=
ot manage to convince you to migrate to GitHub, you will not be able to see=
 my intermediate commits and we together will not be able to go into a make=
 pull-review-update cycle.


On Tue, Dec 30, 2014 at 6:42 PM, Werner Keil <werner.keil@gmail.com> wrote:

I'd say a separate "presentation" element, *Format, *Formatter, *Renderer
or what we think sounds best.

At least JSON would normally be Locale neutral so maybe Renderer sounded
better for that, but other suggestions welcome.

Werner

On Tue, Dec 30, 2014 at 6:37 PM, Reza Naghibi <
reza.naghibi@yahoo.com.invalid> wrote:

> Just to be clear, whats the proposed change?
>
>
>
>
> <div>-------- Original message --------</div><div>From: Volkan Yaz=C4=B1c=
=C4=B1 <
> volkan.yazici@gmail.com> </div><div>Date:12/30/2014=C2=A0 11:12 AM
> (GMT-05:00) </div><div>To: dev@devicemap.apache.org </div><div>Cc:
> </div><div>Subject: Re: JSON toString methods in data classes </div><div>
> </div>I agree. While it is not a big problem, it looks like an ad-hoc hac=
k
> in its
> current form. Further, I believe its consumer's responsibility to pick th=
e
> format for marshalling. Even if JSON is the way to go, we shouldn't be
> writing our own JsonParser class -- whose name implies a parser but which
> is actually a formatter -- and use a more decent library for that purpose=
,
> I believe. Anyway, not a big issue. If the rest approves the change, I ca=
n
> come up with a patch.
>
> On Tue, Dec 30, 2014 at 4:37 PM, Werner Keil <werner.keil@gmail.com>
> wrote:
>
> > Maybe we can abstract that a bit, e.g. a formatter/renderer that offers
> > multiple output options. Whatever is best as default could be used behi=
nd
> > toString() if JSON is best, why not, but it would be good to abstract
> data
> > from the output/representation.
> >
> > Werner
> >
> >
> >
> > On Tue, Dec 30, 2014 at 2:19 PM, Reza Naghibi <
> > reza.naghibi@yahoo.com.invalid> wrote:
> >
> > > JSON is used in our servlet, spring, and console examples.
> > >
> > >
> > >
> > > <div>-------- Original message --------</div><div>From: Volkan Yaz=C4=
=B1c=C4=B1 <
> > > volkan.yazici@gmail.com> </div><div>Date:12/30/2014=C2=A0 5:02 AM
> > (GMT-05:00)
> > > </div><div>To: dev@devicemap.apache.org </div><div>Cc:
> > > </div><div>Subject: JSON toString methods in data classes </div><div>
> > > </div>Hi,
> > >
> > > Is there a particular reason for why are we returning JSON formatted
> > output
> > > from toString() methods of o.a.d.data.* classes? This convention is n=
ot
> > > followed by .NET/VB clients, if I am not mistaken.
> > >
> > > Best.
> > >
> >
>


------=_Part_3072834_461289202.1420033111923--