Re: AS = Status+Updates?

In fact, because of this, to complement existing Activity Streams support 
in IBM Connections, we introduced a separate microblogging API (structured 
similarly but at a different endpoint), documented here ->
http://www-10.lotus.com/ldd/lcwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Connections+5.0+API+Documentation#action=openDocument&res_title=IBM_Connections_Microblogging_API_ic50&content=apicontent


The key difference being - 
The Activity Stream is referential - the core data exists elsewhere (or at 
least did at some point)
Microblogs are themselves data - a post to this API exists nowhere else
Once we receive a microblog post, we actually create a corresponding event 
and place it in the appropriate streams (having considered who should 
receive it based on 'following', 'network' and @mention considerations).


Rgds,
-Bill.


Bill Looby 
Software Architect 
IBM Analytics

Phone: +353 1 8155129 
E-mail: bill_looby@ie.ibm.com



 
 



From:   James M Snell <jasnell@gmail.com>
To:     Sandro Hawke <sandro@w3.org>
Cc:     "public-socialweb@w3.org" <public-socialweb@w3.org>
Date:   07/05/2015 16:12
Subject:        Re: AS = Status+Updates?



On Thu, May 7, 2015 at 6:10 AM, Sandro Hawke <sandro@w3.org> wrote:
> Summary:  it might be good to re-organize AS2 to separate the CRUD
> operations from the "social" vocabulary
>

AS2 does not have any CRUD operations.

When I send something like the following to a server, I'm notifying
not instructing:

  POST / HTTP/1.1
  Host: example.org
  Content-Type: application/activity+json

  {
    "@type": "Follow",
    "actor": "acct:joe@example.org",
    "object": "acct:sally@example.org"
  }

Depending on the server, there might be some side effects that occur
after receiving the POST, but the AS2 payload itself does not carry
any behavioral semantics or expectations whatsoever.

> Thinking about Activity Streams in light of this last meeting, where I
> finally came to understand the role it plays in Activity Pump, I'm 
wondering
> if it would be good to change the design in a fundamental way.  I'm 
sorry I
> didn't understand this well enough to say it months ago.
>
> Right now, as I understand it, an Activity describes a change in the 
state
> of the world.  I think it might be good to instead have a way to 
describe
> the state of the world and a separate way to talk about state changes. 
We
> could frame it like this:
>
>  * A "status" is a post which states something about the world at some 
point
> in time.
>
>  * An "update" is a post which creates, modifies, or deletes a status.
>

It makes sense to create such distinctions within the API but not the
AS2 spec itself.

- James

> In the common case where one is just creating a new status, there's 
minimal
> value in separating them.   But when you think about fixing a typo in a
> Note, and how you propagate that change, and who should be sent that 
change,
> and who is allowed to see that change, and how to efficiently distribute 
the
> change, and who has permission to make the change, ..., and what happens
> when a server is down and changes can't be sent right now, ... then I
> suspect things become a lot simpler when we separate them.
>
> The "social API" then can consist of doing CRUD on status resources. 
Those
> CRUD operations might be done by creating updates (something like
> update/delete in micropub) or more directly using http verbs as in LDP 
or a
> whole bunch of them might be streamed in a JSON-LD document (as I think
> ActivityPump envisions).   The federation protocol can largely consist 
of of
> sending around Updates.   The updates can also be kept around as a 
change
> log.
>
> I'm interesting in spelling this all out in more detail if others think 
it's
> promising.
>
> I suspect the pushback will be that it's somewhat harder to implement 
very
> simple systems.   The payoff doesn't come until you want ACLs or 
federation
> or something else non-trivial.    Beyond that, are there are other 
problems
> with this style?
>
> My apologies if I'm missing something obvious that makes this clearly a 
bad
> idea.
>
>      -- Sandro
>
>