Benefits of this over POJO for client-side

[gobengo]

Big AS fan here. Pardon my ignorance with these questions.

What use cases do you have in mind for this library on the client?

What benefits would I get from modeling activities I'm consuming with this instead of just plain old JS Objects? I see that it creates objects with all of the valid AS fields pre-defined on the instance. But usually the value is undefined still. So is that any more valuable than never assigning to the key? And wouldn't the latter be more memory efficient?

I see in some of the demos that things like activity.verb.id is defined even if you just construct with verb as post. What is the guarantee about what .id is and when it will and won't be defined?

It's also not obvious to me what this is for activity.object.content['*']

Finally, I tried the node example from the README and got 'toString is not a function' exceptions on this line in node 0.10 and 0.11. Oddly, typeof Object.getPrototypeOf(activity).toString === 'function' was true, but the accessor wasn't working right..

console.log(activity.toString());

[gobengo]

One other 'feature' seems to be that, given a simple AS on the way in, the resulting model with have JSON-LD '@' values and context automatically.

[jasnell]

The js library wraps the plain js objects and wraps some utility function around it. For instance, since link values can be strings, objects or arrays, the wrapper abstracts the details and ensures that there is a consistent way of accessing those. Same with Type Values and Natural Language Values. The activity.object.content['*'] for instance is used when content is represented as a language map and you want to grab the specific language value that matches the user agents configured default language.

I purposefully wanted to keep this library fairly light in terms of functionality. It doesn't replace using the plain javascript object itself directly, it's just intended to augment and normalize it somewhat.

[jasnell]

I do want to incorporate the json-ld processing into this as an optional feature but haven't had the chance to do so... Please submit issue reports for any bugs you find and I'll get to them... I'm hoping to have the time to return to this code late next week.. if you're willing, I'd love to accept pull requests :-)

[gobengo]

Thank you for the context.

To promote client-side interop projects for JSON-LD outside of activitystreams, it'd be great if future JSON-LD functionality was provided as a project independent of activitystreams.js, and this just depended on it.

I will ponder more as I work on some current projects that this is relevant to, including AS2.0 adapters to all the Web Components here: http://apps.livefyre.com/