social
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social] More internal use of ActivityStreams?


From: Mikael Nordfeldth
Subject: Re: [Social] More internal use of ActivityStreams?
Date: Wed, 02 Jan 2013 17:26:17 +0100

On ons   2 jan 2013 16:14:55, Melvin Carvalho <address@hidden> wrote:
> -1
> 
> Activiity streams is a neat idea, and a few years ago when the protocol
> started it was promising in that it was an early embracer of the JSON
> paradigm.   JSON, imho, is an excellent choice for developers in that you
> can easily serialize it into most languages.

Actually, I prefer AS because it's also defined with XML somewhat. Even though 
the base schema only specifies json nowadays.

Given that the very promising networks surrounding XMPP would interact 
splendidly with properly namespaced XML schemas (i.e. activitystreams as used 
in BuddyCloud etc.), it's much better for interoperability than any JSON 
namespaceless serialization.

> Today there are several first class
> JSON serializations, better engineered, with better interop and with
> better adoption.

I'd like to cite the "running code" part of 
http://en.wikipedia.org/wiki/Rough_consensus and quickly end this abstract 
discussion on would-be utopian serialization standards.

It's all just ones and zeros. If you're proposing something truly awesome, like 
ternary computing protocols I might be persuaded into discussing a possible 
migration. I doubt anyone else would, though.

> There is also the issue of the proprietary nature of activity streams.   I
> would be much happier if they were to put it under creative commons.   It
> is the only spec that I know where it has been delayed in order to get
> approval form lawyers.

APIs and similar specs are AFAIK not subject to copyrights or patents, 
following the result of lawsuits like Oracle vs. Google on the Dalvik engine.

> I dont want to be too unkind to AS as my name is on the spec :)     But I
> would consider it one of the weaker serializations that should be
> supported as legacy, if there is a very compelling reason to do so. 

Are there any inherent restrictions that will make it [practically] impossible 
to use activitystreams in future federations with other software? Will our 
social networking change so radically that we no longer "share" or "comment" 
stuff that have one or several objects possibly containing other objects?

If so, how far into the future is that? And would it be easier to migrate from 
GNU Social's current homebrew structure - or something properly specified like 
ActivityStreams?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]