Subject: [apps-discuss] JSON Patch: Shortening operation names?

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 05 Dec 2011 17:55:58 -0800

It's been suggested on more than one occasion that the operation names
in JSON Patch are too verbose. I've countered with the point that if you
transmit via HTTP and "Content-Encoding: gzip", the verbosity is nicely
compressed out. This argument has served me well (insofar as it tends to
silence most critics), but I continue to get challenged on this point.
I'm curious to know what position APPSAWG members may have. Should I use
"rm" or even "-" instead of the more verbose "remove"?

Paul

---

From: Tony Hansen <[email-masked]>
Date: Mon, 05 Dec 2011 22:45:15 -0500

I believe it was Ken Thompson, when asked what he would have changed 
about unix, who said he would have spelled "creat" with an "e" at the end.

     Tony Hansen
     [email-masked]

On 12/5/2011 8:55 PM, Paul C. Bryan wrote:
> in JSON Patch are too verbose. I've countered with the point that if 
> you transmit via HTTP and "Content-Encoding: gzip", the verbosity is 
> nicely compressed out. This argument has served me well (insofar as it 
> tends to silence most critics), but I continue to get challenged on 
> this point. I'm curious to know what position APPSAWG members may 
> have. Should I use "rm" or even "-" instead of the more verbose "remove"?

  * English - detected
  * English

  * English

<javascript:void(0);>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 09:27:32 +0100

> "rm" or even "-" instead of the more verbose "remove"?

I can live with full names, but wouldn't object to ultra-short names 
such as "+", "-", "?" etc either.

Best regards, Julian

---

From: Graham Klyne <[email-masked]>
Date: Tue, 06 Dec 2011 10:28:07 +0000

I'd be inclined to stick with the readable names, unless there's a clear case 
that the extra bytes will have significant effect on performance.

[[
Donald Knuth made the following two statements on optimization:

"We should forget about small efficiencies, say about 97% of the time: premature 
optimization is the root of all evil"[2]

(He also attributed the quote to Tony Hoare several years later,[3] although 
this might have been an error as Hoare disclaims having coined the phrase.[4])

"In established engineering disciplines a 12 % improvement, easily obtained, is 
never considered marginal and I believe the same viewpoint should prevail in 
software engineering"[2]
]]
-- http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

I'd be surprised if, in practice, the shorter names would yield a >10% improvement.

#g
--

On 06/12/2011 01:55, Paul C. Bryan wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Dave Cridland <[email-masked]>
Date: Tue, 06 Dec 2011 12:18:01 +0000

On Tue Dec  6 10:28:07 2011, Graham Klyne wrote:
> I'd be inclined to stick with the readable names, unless there's a  
> clear case that the extra bytes will have significant effect on  
> performance.

Shrt nms tnd 2 rduc rdblty 4 0 effct.

Put another way, reducing the length of the names is merely making  
particular packets shorter. This is likely to have an effect only if  
using certain low-level network types (such as 3G mobile), and if the  
middle layers arethemselves sufficiently terse. I've been assuming  
(without, I hasten to add, reading the draft) that this is all going  
over HTTP, which will render any saving to be a wasted effort.

If we're running under some more optimal protocol, and over a  
link-layer which is genuinely low bandwidth (like SATCOM, HF, etc)  
then yes this will make a difference, but also you can use deflate,  
and in extreme cases you can preload the dictionary with typical  
patch operations, which is quite likely to reduce the names to  
fractional bytes very effectively.

Finally, on HTTP itself, running over TLS with compression enabled  
will yield much lower bandwidth then a C-E, for payloads of this  
type, so that's a much more effective argument.

(A small note - it *would* be worthwhile reducing the verbs if the  
distance between JSON patch operations - that is, the size of the  
entire HTTP request, uncompressed - would exceed 32k, and making it  
more terse would bring it radically under.)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 14:07:40 +0100

On 2011-12-06 13:18, Dave Cridland wrote:
> ...

Actually, readability is the main reason why I would support such a 
change; in a diff format, using a single-character notation might 
*improve* the readability (compare to the traditional diff format).

Best regards, Julian