Re: [apps-discuss] JSON Hypertext Application Language

[Mike Kelly]

Hi James,

Thanks for sharing your thoughts, I have some follow up questions in line

On Sat, Jun 9, 2012 at 5:51 PM, James M Snell <jas...@gmail.com> wrote:
> On Sat, Jun 9, 2012 at 12:55 AM, Mike Kelly <mikeke...@gmail.com> wrote:
>> On Sat, Jun 9, 2012 at 2:04 AM, James M Snell <jas...@gmail.com> wrote:
>>> HAL will just be way too verbose to be practical.
>>
>> I think 'way too verbose' is overstating the importance of this. You
>> are the first person to raise this as an issue at all, let alone as a
>> significant one.
>>
>
> Deep breath please and consider the *complete* statement I made... which was:
>
>  There are valid arguments for both, for certain, but I can see many
>  scenarios where HAL will just be way too verbose to be practical.
>
> Please allow me to stress the parts where I said, "there are valid
> arguments for both" and "I can see many scenarios..."
>
> It would be highly counterproductive to assume that HAL is appropriate
> for all possible scenarios; all my feedback was intended to do was
> indicate that, for the subset of interesting and relevant cases I've
> worked with in the content and activity syndication space, complex
> link structures tend towards overkill. That's not to say there's no
> place for them, not by any stretch of the imagination.

To be clear, there's no anxiety or animosity from my end on this - I'm
simply trying to understand why you would pick such emotive language
as "way too verbose to be practical" when all we're really talking
about is a very small difference in design. I understood your
rationale for proposing your slightly optimised alternative for
activity streams. I did (and still don't) understand why you believe
HAL's slightly-less-optimal approach to be so significant as to render
it "way too verbose" and/or "impractical".. at worst it's marginally
sub-optimal for some basic use cases.

>> Link Objects are necessary to allow for the "templated" indicator (for
>> when the link is a URI Template), for including the additional link
>> params established in the Web Linking RFC, and to provide the
>> opportunity for extension of link objects in any future types wanting
>> to extend HAL e.g. by adding additional controls or hints.
>>
>
> Ok. That all granted, for the majority of cases I've worked with, when
> you boil everything down, I still, most often, only need a url and a
> rel.

A rel and a url are all that is required to produce a valid link with
HAL. This is a valid link object:

{ "foo": { "href": "/bar" } }

Just to re-iterate, HAL's linking conventions have been around for
just under 2 years now, and you are the first person to consider this
a pressing issue.

>> Fwiw, I did actually consider also adding a direct string as you have
>> suggested here but decided against in the interests of
>> simplicity/consistency, given that the Link Object approach is
>> unavoidable (for the reasons stated above).
>>
>> On another note - HAL has been established for a while now (as a less
>> formal, public specification) and has a growing list of server and
>> client tooling, seems to me like it would be a win for Activity
>> Streams to adopt HAL's already established conventions, given that
>> your recent new proposal is so close to it anyway.
>>
>
> If the HAL spec is being used to address real application problems,
> then that's fantastic. For activity streams, my opinions tend to be
> driven more by the specific implementation requirements and a desire
> to keep things as simple as they possibly can be. My note was merely
> intended to provide (hopefully) constructive feedback from the
> perspective of someone else who has dealt (many many times) with the
> notion of generic linking mechanisms in JSON and XML data formats.
> Take it for what it's worth.

So, just to clarify.. your desire for simplicity is so strong that a
very minor optimisation that will:

- harm the expressiveness of links
- damage future extensibility
- not benefit from existing libraries

is still 'the right option' for activtity streams over adopting a
design that has existed for almost 2 years, has seen decent adoption
and brings with it a handful of libraries in various programming
languages?

Maybe I've missed something vital but at the moment I do not
understand where you are coming from.

Cheers,
M