-
Notifications
You must be signed in to change notification settings - Fork 332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ActivityStreams 2.0 #1483
ActivityStreams 2.0 #1483
Conversation
routes/api.js
Outdated
@@ -303,7 +311,7 @@ var getObject = function(req, res, next) { | |||
next(err); | |||
} else { | |||
obj.sanitize(); | |||
res.json(obj); | |||
res.json(wantAS2(req) ? as2(obj) : obj); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thinks this could be put in a function like "handleAS2" for prevent repeating code (line 547 is the same code)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch, thanks 👍
Fixed this locally, will push soon
2 similar comments
The tentative plan is to capitalize all verbs that have been straight up dropped and rename verbs when they have been fully renamed or subsumed by another Activity type. We'll do the same for object types, but we'll use Here's the complete list of differences between AS1 and AS2 verb vocabularies:
And here's the list of object type vocabulary differences:
|
Thats a lot of changes... is there a way to tell a client that terms are deprecated and give them a chance to adapt? Did the endpoint change or is there a version number so a client can tell that it wont work now? Just thoughts... Not sure whats truly necessary for activity streams migration |
lib/as2.js
Outdated
as2["@id"] = as2.id; | ||
delete as2.id; | ||
|
||
if (as2.verb === "post") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you change the verb, need to change this #L145 or change the name of Activity.prototype.apply[Method]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need to change anything outside of this file since this runs so late in the request-response cycle. Basically everywhere else doesn't have to care.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You only change the output/response?
What will happened with the petitions?, if comes the request with AS2, it transform to AS1 before process/save?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vxcamiloxv we don't support AS2 submissions yet but when we do that'll be how it works. At least for the time being.
Eventually we'll want to move to AS2 storage but. Not yet. We want the API to stabilize, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think will be strange (and confusing), if the input is AS1 and the output AS2, for the external apps could be more work (migrate the output and later the input) and probability cause more side effects and more errors.
I think is better one big change a not change by parts, is better one migration than 2 big migrations in a short period of time, mostly when is related with the input/output of a API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vxcamiloxv I would agree with you except that AS2 output is opt-in. So if clients don't want to deal with the hassle of consuming two different formats in input and output (I certainly wouldn't), they don't have to. They can just wait for AS2 input to ship too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha ok, yes, probably they will wait for full implementation
@detrout endpoints do HTTP content negotiation. Clients only get this representation if they specifically ask for AS2 in the |
So to be clear, this is fully backwards-compatible and will ship as semver-minor. |
Since writing this vocab plan I've found https://github.com/snarfed/granary (/cc @snarfed); we should try to align with that processing model. Otherwise I think this is ready to implement. |
So quick note: It seems there's no for the rest, I'm more than willing to test stuff against Kroeg for interop testing :P |
b58ff4e
to
3df16ad
Compare
4c83afc
to
93b2c92
Compare
Here's the current list of TODOs:
|
If people complain, we can readd these. But better to start with them gone and add them later, rather than have to go through a full semver-major cycle in order to remove them later. Also, these were dropped for a reason. There was no actual evidence of `upstreamDuplicates` and `downstreamDuplicates` being used, and `title` was deprecated for similar reasons. So it just doesn't seem worth supporting them.
Test using OAuth 2.0 with the actor route. This required the following changes: - Bearer tokens in the configuration file format - Loosen anyReadAuth() to allow OAuth 2.0 - Change the profile route to do content negotiation - Change Actor test to provide a bearer token
@evanp to answer your question on IRC - I'm down to merge this whenever provided that a) tests are passing and b) nothing is half-implemented or whatever. I'll try to do a code review tonight 👍 |
avoid problems
Resolves #851