Re: Why not AS2? was Re: Getting the group back on track

On 2015-10-18 14:10, Sandro Hawke wrote:
> On October 17, 2015 10:45:34 AM EDT, Christopher Allan Webber
> <cwebber@dustycloud.org> wrote:
>  >Sandro Hawke writes:
>  >
>  >> On 10/16/2015 09:34 AM, Christopher Allan Webber wrote:
>  >>> This is great news. So that's MediaGoblin, Diaspora, Pump.IO,
>  >>> Friendica, the Clojure stuff from Thoughtworks, IBM's project (I'm
>  >>> forgetful of the name), and from my conversations off-list, quite
>  >>> possibly OwnCloud. It looks like the willingness to implement AS2
>  >is
>  >>> fairly strong in those groups.
>  >>>
>  >>> I agree with you that the serialization format is hardly the only
>  >>> critical point to be discuss, but figuring out at least that is a
>  >>> requirement to move forward on nailing down other things.
>  >>>
>  >>> Here's where this group is frequently stuck now: http://shed.bike/
>  >>>
>  >>> Again, we have to agree on a format before we move forwards on other
>  >>> things. It may as well be our deliverable.
>  >>>
>  >>> Kevin Marks raised in the last meeting that there seems to be a
>  >>> disagreement about whether or not this group is to build something
>  >>> prescriptive and defining a standard, or evaluatory and summing the
>  >>> state of the field. I agree that there's disagreement over this!
>  >We've
>  >>> already done a lot of the latter, summing the state of the world and
>  >>> doing evaluation; I want to use that information to move on to
>  >actually
>  >>> building something people can implement. That requires making
>  >>> decisions.
>  >>>
>  >>> <kevinmarks> cwebber2: I found this quote that sums up well what I
>  >am getting
>  >>> at:
>  >https://kindle.amazon.com/post/HLglK_6oRhOnsiQSo829eg
>  >>>
>  >>> So, it's true that things change over time, and wikis are great, but
>  >we
>  >>> already have wikis that are discussing these things. I don't think
>  >we
>  >>> need a group at the w3c to continue a wiki process that is already
>  >>> working well outside it.
>  >>>
>  >>> I want to define a standard, and move forward with it. I'm burning
>  >>> resources to spend on this, and that burn time will run out if we
>  >can't
>  >>> move ahead.
>  >>>
>  >>> I may have raised things poorly in the last meeting by suggesting
>  >that
>  >>> we agree on ActivityStreams as a MUST requirement. How about a
>  >SHOULD?
>  >>>
>  >>> If we agree on SHOULD, at least, we can move forward.
>  >>>
>  >>> If this group can't agree on "SHOULD" of its own standard, something
>  >is
>  >>> totally bonkers here.
>  >>
>  >> I understand proposing SHOULD as a compromise, but let's push a
>  >little
>  >> more on MUST, first, and see if we can deeply understanding what's
>  >> motivating the -1's.
>  >>
>  >> Trying to think about what's going to maximize utility in the
>  >industry,
>  >> and help the people who want AS2 to succeed, it's not clear to me in
>  >> picking between two bad options whether it would be better to go with
>  >a
>  >> SHOULD or go with a MUST over formal objections from several people.
>  >>
>  >> It depends a lot what motivates those -1's, I think.
>  >>
>  >> When one puts a SHOULD in a spec, I think one should be clear about
>  >at
>  >> least some of the reasons one might have for going against that
>  >> recommendation. Can someone name a reason they'd have for not
>  >> implementing AS2 in the kind of software that might implement AS2?
>  >>
>  >> -- Sandro
>  >
>  >Thanks Sandro, I agree that understanding why we got these -1s in the
>  >first place would be helpful.
>
> Thinking about it a little more, perhaps I can answer my own question.
>
> First I want to note that HTML doesn't say one MUST use CSS for style or
> JavaScript for script. It carefully leaves to door open for them to evolve.
>
> With that in mind, one can image there's a strength in loose-coupling
> and allowing various parts of the system to evolve independently.
> Particularly if someone can imagine something better/simpler/faster/etc
> than AS2, why should they have to burden their system with AS2 code just
> to claim they fully implement the social API or federation system? In
> fact, even if we say they MUST implement it, in practice if they have
> something better, they'll just ignore the MUST anyway.
>
> So we could say "SHOULD unless you have a better alternative and no need
> to be interoperable with folks using AS2". Or we could be like HTML and
> just leave it open with the knowledge there's a well-known primary
> contender.
>
> - Sandro
>
>

In my world view...

The design of the Social API doesn't need to rely on any particular 
vocabulary. People will use whatever vocabulary they deem to be 
appropriate to describe their own "social" data. The Social API will 
merely enable the data to be passed. The challenge for the Social API is 
to lay down some form of a common denominator of the social API-like 
things that's needed. IMHO, the API shouldn't be restricted to the 
current candidates (with varying degree of quality and coverage): 
ActivityPump, MicroPub, SoLiD. Certainly there are other decentralized 
approaches out there which should be studied?

What I suspect will happen is that, there will be some general 
clustering or convergence on the data models, e.g., activity/stream of 
events (like AS2), relations between agents and things i.e., to other 
agents or documents. So, those in which buy into the activities 
perspective will adopt/extend AS2 because there is something for them - 
this is all what this WG is putting on the table. We are certainly not 
covering all aspects of the social web, neither should we presume to or 
force it as such via a specific vocabulary.

-Sarven
http://csarven.ca/#i

Received on Sunday, 18 October 2015 19:25:14 UTC