In my opinion having to trim the value is a miniscule annoyance compared to
have an increasing number of redundant virtual directories.
Vajk
On Mon, Mar 17, 2014 at 6:49 PM, Jerry Scharf <
sch...@lagunawayconsulting.com> wrote:
> Michael,
>
> I agree with Paul on this. I think it is wrong to make a change to the
> existing behavior for this kind of reason. The law of least surprise
> says that what people have seen as OWFS output for the last decade
> should be the default way it continues to output things.
>
> It's not a question of whether people could make the changes to the new
> form, it's a question of forcing every app that expects the current form
> to rev so new apps don't have to strip the white space. There are
> probably apps that work and people use that have gone out of support, so
> breaking things is a big deal.
>
> If the issue is only for programming interfaces, it seems easy to either
> add an argument to wget to indicate whether it is stripped or not with
> the default being not stripped. You could also have a separate routine
> that returns a stripped version of a message so that every user does not
> need to invent their own. You could even add a text/JSON routine so that
> it is all done once.
>
> If this is to change the way OWFS looks, then Paul's idea of a
> pseudodirectory that indicates a stripped version is desired seems like
> a good way to approach it. For owhttpd, you could do a command argument
> that tells it to display everything in a stripped form.
>
> just my $.02.
>
> jerry
>
> On 03/17/2014 08:08 AM, Michael Markstaller wrote:
> > Thanks Paul,
> >
> > I understand, just asking myself if changing this in the backend would
> > really break something?
> > Understand it looks nicer in owget - but anywhere else it is
> > programatically just annoying..
> >
> > I guess any client/function has to implement some parser for removing
> > the leading whitespaces to get the value so it won't break much -
> > although I might oversee something(?)
> > But at least in owhttpd/text/Json they are useless overhead IMHO.
> > In owget in breaks using it with simple (Ba)sh like let without working
> > around the leading spaces first etc.pp.
> >
> > Lets hear other thoughts on this..
> >
> > Michael
> >
> > On 17.03.2014 15:13, Paul Alfille wrote:
> >> The values are formatted with the standard C format parameters: %d, %u,
> >> %G in /module/owlib/src/c/ow_parseoutput.c With no particular reason to
> >> choose otherwise, no left-justification was done. The default
> >> justification looked better when printed out (it tended to stack better
> >> in tables).
> >>
> >> Although it would be trivial to change, I worry the effect on existing
> >> applications. We could always add another "flag" in the path name, Say
> >> /trim/10.123123233/temperature if its important enough.
> >>
> >> owget has no conception of the return value, it's just a string, so any
> >> change would have to be upstream.
> >>
> >> owhttpd would be easy to change, particularly the json implementation
> >> where the raw data is probably never presented, but rather interpreted
> >> first. owhttpd does know about the type of value. (It would be changed
> >> in /module/owhttpd/src/c/owhttpd_read.c) Currently owhttpd only formats
> >> differently for binary and bitfields, but that could be changed.
> >>
> >> Paul
> >>
> >>
> >>
> >> On Mon, Mar 17, 2014 at 9:36 AM, Michael Markstaller <m...@elabnet.de
> >> <mailto:m...@elabnet.de>> wrote:
> >>
> >> Hi,
> >>
> >> one question/suggestion:
> >> I have in several clients/languages for each and every query a
> >> left-trim-function to remove the leading spaces in the output of
> values
> >> of owget,owhttp(text/json),..
> >>
> >> What are these leading spaces good for?
> >> In the libow they might make sense (which=?) but in
> >> owget/owhhtpd(text/json), couldnt they just be removed before in
> owfs?
> >>
> >> Michael
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
