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: JSON toString methods in data classes
Date Wed, 31 Dec 2014 13:38:31 GMT
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 below is vague and
generic. This is bad for feature development.

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

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

      From: Volkan Yazıcı <volkan.yazici@gmail.com>
 To: "dev@devicemap.apache.org" <dev@devicemap.apache.org> 
 Sent: Wednesday, December 31, 2014 5:38 AM
 Subject: Re: JSON toString methods in data classes
   
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 Device/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 this issue in a separate thread.
In the attachment, you can find the following two patches: 1) Remove JsonParser from Java
client and 2) improve servlet example. Since I still could not 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ıcı
<
> volkan.yazici@gmail.com> </div><div>Date:12/30/2014  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 hack
> in its
> current form. Further, I believe its consumer's responsibility to pick the
> 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 can
> 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 behind
> > 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ıcı <
> > > volkan.yazici@gmail.com> </div><div>Date:12/30/2014  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 not
> > > followed by .NET/VB clients, if I am not mistaken.
> > >
> > > Best.
> > >
> >
>




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