Re: User Hypermedia format

mike amundsen <[email protected]> Fri, 28 Feb 2014 14:41:21 -0500
Newsgroups gmane.comp.web.services.rest
Message-ID <CAPW_8m6+vTor-vtTRVTh3YgkXNOfaiWpYfp5VQ_Vf=np4OkNtg@mail.gmail.com>
understood:

so in the XML flavor you certainly can do a CDATA pattern and embed a
custom object in the message. this reduces it's usefulness to anyone except
those who write custom apps (or use your custom libs/plugins) that
understand this embedded object.

i suspect we can set up some similar thing in the JSON variant (the ability
to embed arbitrary objects/trees in an Uber msg) and the same would apply -
only those pre-built to understand what's already coming would be able to
use that representation.

of course, this assumes that the idea of existing Uber clients being able
to read/process/display your data w/o additional custom coding is even a
value for you. it may not be.


Now, to back up a bit.

1) is this really about programmer optimization? id yes, a few bits of code
that translates the internal data into Uber is not a big deal and could
solve that problem.

2) is this about payload size? i don't think uber adds much weight at all
here (the JSON flavor is certainly more compact than the XML one). and when
you're talking about 180,000 data points. that's a pretty big chunk of data
anyway. you're free to use compression on the outbound with will greatly
reduce the added weight since repeated chars compress very nicely.

3) finally, what format are you using now? have you looked at HAL? it is
designed to host arbitrary objects in a wrapper.  I'd be interested to see
some comparisions (custom format, HAL, Uber) not just of size of the
representation but also the size of the compressed response and the cost to
process (surely the Uber will be the most costly to process, right?)

anyway, this is all good stuff and i'd love to follow up on what you're
doing now and how a change to something like Uber will make things diff for
you.






mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Fri, Feb 28, 2014 at 2:13 PM, Matt McClure <[email protected]>wrote:

>
>
> I'm concerned about verbosity of the messages as well as programmer time
> and experience.
>
> For example, I've been working with high resolution time series fitness
> data. Conceptually it's array like. There might be tens of samples per
> second of 1-10 different metrics, and 30 minutes is a typical duration. I'd
> like a format that just let me represent that part of a message as a
> compact first class array.
>
> --
> http://matthewlmcclure.com
>
> On Feb 28, 2014, at 11:58 AM, mike amundsen <[email protected]> wrote:
>
>
>
> (copying back to the list)
>
> all good Qs...
>
> "How does the XML format represent true, false, and null?"
> ****
> so far, the approach i have is to treat this all as text data:
> <data transclude="false" />
>
> it's possible to go further into this space using XML Schema, but I am not
> really interested in backing that into the format design. You could
> *definitely* use it by adding a <data url="..." rel="schema" /> element at
> the top of a representation. if that's what you want do to.
> ****
>
> "How does the XML format represent objects and arrays? (Some sadist will
> put JSON in there unless we have a better answer.)"
> ****
> in XML there is no intrinsic Array pattern, just an implied one
> <data rel="collection" ...>
>   <data rel="item" ... />
>   <data rel="item" ... />
> </data>
>
> is usually converted into an array in code.
>
> JSON does this differently, of course by *requiring* explicit use of Array
> in the representation.
> ****
>
> "More generally, I imagine your intent is to constrain clients to adopt
> more of a tolerant reader approach and use less automatic serialization and
> deserialization."
> ****
> bingo! ;)
>
> my designs almost always attempt to downplay direct serialization
> into/from code. The trouble is programming languages can change over time
> and I'd like to make sure my designs don't favor (or become dependent) upon
> a sub-set of programming languages.
> ****
>
> "At the same time, I think there's potential value in making compound,
> complex data more of a first class citizen. Allowing bare object and array
> data representations (not serialized into a quoted string) would let
> clients and servers reach inside the data without additional explicit
> deserialization steps."
> ****
> Keeping in mind what you describe here is a "programmer optimization"
> there are lots of ways to do this. We all got used to converting XML into
> code by way of "black box" functions in a language. We also got used to
> converting JSON into code in languages that didn't have the same internal
> structure as javascript. we did this w/ black box code.
>
> We can do the same with Uber (or any format, really). We need a DOM for
> that ,but it's not too hard; esp. with something like Uber that allows for
> recursion in the model.
> ****
>
> "I guess one risk of allowing objects and arrays is the antipattern of
> using a single data element whose value is a very complex object."
> ****
> right, the killer is that messages become "envelopes" for code. this is
> what i am trying to avoid. I am trying to design format where messages are
> messages "all the way down" ;)
>
> this means there is "heavy lifting" in creating the message
> (serialization) and parsing it for use ("de-serialization") and I want to
> keep that heavy lifting in code on each end - not in the message design
> itself.   For example the appeal of JSON is that there is "zero" lifting if
> you are writing javascript. However, that value dwindles as you get into
> other languages (erlang, python, etc.).
>
> "What are the tradeoffs you're trying to balance?"
> ****
> i'm experimenting here with ways to make it easier to express a wide range
> of use cases in a minimal format. and ways to make it easier to
> parse/validate the message regardless of platform or language.
>
> in my Cj design i actually created a design that gave a bit "middle
> finger" to serializers everywhere<g>. i also tried to make to really hard
> to pass recursive messages by forcing a very flat structure in the message
> model.
>
> with Uber, i am working on the other end of that set of values. i want to
> create a model that leads devs into creating recursive messages. but I am
> still working to thwart attempts to create code envelopes. Uber is a kind
> of "proxy" for objects on either end of the convo, not a "high-fidelity
> object tree tunnel" (if that makes any sense).
>
> hope this helps and love to hear more from you on this.
>
>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
>
>
> On Thu, Feb 27, 2014 at 1:40 PM, Matt McClure <[email protected]>wrote:
>
>> Mike,
>>
>>
>> On Monday, February 24, 2014, mike amundsen <[email protected]> wrote:
>>
>>> I've also added some text to the "value" definition to say JSON format
>>> MUST only be set to string, number, or literals (true, false, null) and
>>> MUST NOT be set to object or array. What is then implied (not yet stated in
>>> the prose) is that, to pass arrays or objects in the "value" attribute, you
>>> need to *escape* the object/array and pass as a string.
>>>
>>
>> How does the XML format represent true, false, and null?
>>
>> How does the XML format represent objects and arrays? (Some sadist will
>> put JSON in there unless we have a better answer.)
>>
>> More generally, I imagine your intent is to constrain clients to adopt
>> more of a tolerant reader approach and use less automatic serialization and
>> deserialization.
>>
>> At the same time, I think there's potential value in making compound,
>> complex data more of a first class citizen. Allowing bare object and array
>> data representations (not serialized into a quoted string) would let
>> clients and servers reach inside the data without additional explicit
>> deserialization steps.
>>
>> I guess one risk of allowing objects and arrays is the antipattern of
>> using a single data element whose value is a very complex object.
>>
>> What are the tradeoffs you're trying to balance?
>>
>> Matt
>>
>>
>> --
>> Matt McClure
>> http://matthewlmcclure.com
>> http://www.mapmyfitness.com/profile/matthewlmcclure
>>
>>
>
>
>
> 
>