In case you missed it,…

In case you missed it, version 0.8 is out, albeit a little late. I also didn’t get around to posting the meeting notes from last week, so here’s a quick roundup:

One Consumer Per User vs Independent Consumers / Consumer Registration
We’re going to go with independent consumers, because we kind of have to. The conversation turned to how we register new consumers, and a number of interesting ideas were floated: creating a central repository on where consumers like mobile apps can register, for example. We’re going to circle back around to both this and scoped tokens after we get the initial OAuth stuff settled.

In order to load the correct plugins, we’re probably going to have to go with per-domain API endpoints (e.g. nacin pointed out that we could hack around to avoid this in ms-settings.php, but it’s a bad idea. Whatever we use here is going to be a compromise, and this seems like the best one. Also worth mentioning that we have a multisite-specific plugin that needs some serious love.

This Week
I’d like to push out two releases this week so that we hit 1.0 before Christmas. The plan currently is 0.9 on Tuesday (post-meeting) and 1.0 on Saturday. We’ve got a few issues that still need pull requests before 0.9. Importantly, I really want to get tests happening this week, either in 0.9 or 1.0, as we really need them. We’ve already been bitten by a compatibility issue.

We also need to land authentication this week. The initial version that I’m working on has no UI at all, but follows the independent consumer model as discussed. The UI we can work on later, after we ensure that the authentication works properly.

The meeting this week is…

The meeting this week is coming up in ~17 hours (Monday 9th at 21:00 UTC, Tuesday 10th at 07:00 AEST, Monday 9th at 16:00 EST, Monday 9th at 13:00 PST). Here’s what I’d like to discuss:

Any other topics you’d like to discuss?

I’ve been messing around with…

I’ve been messing around with the WooCommerce code for OAuth, and unfortunately it has API consumers (that is, applications) tied to users. This is a pretty limited method, but it simplifies the code and flow a lot. The question is, do we want core to be limited to this extent, or do we need to think about something more complicated? With this sort of flow, we can show the user’s API key/secret on their profile page, and they just need to fill that in to their application. (We could also add an xAuth flow, where the application can request those keys via Basic authentication.)

Alternatively, we treat consumers as an entirely separate entity, which can then prompt users to authorise them. This is the more traditional OAuth flow that you see with Twitter, Facebook, etc. This increases the application complexity a bit, but allows a site admin to manage applications rather than having it managed per-user. It also allows “rogue” (misbehaving/compromised) application keys to be revoked, rather than requiring each user to regenerate a key/secret.

I’m on the fence about this one. There are benefits to both approaches, and I’ve summarised these below:

One-consumer-per-user Independent consumers
Setting up User copies key/secret from profile page into application Application developer registers via site admin, application directs user to authorise the application
Managing All applications share key/secret Applications registered via admin panel
Revoking Users have to regenerate keys and change all existing applications Admin revokes application
Site UI Key/secret fields on user profile page Consumer management settings page

If you can think of any other points here, post in the comments. I think it’s fairly split between the two at the moment, so I can’t really decide.

I’ve put up an anonymous…

I’ve put up an anonymous feedback form on Google Docs. If you have anything to say about the project, the team, project management or anything else, please use it. Feel free to suggest new features there as well. This is a resource for everyone to use, no matter how involved you are with the project.

Regardless of whether you’ve been involved with WordPress for a long time or you’re a newcomer, regardless of how proficient you think you are, you have something to contribute to the project. There’s nothing worse from my perspective than seeing people discuss issues on other forums that I didn’t even know existed, then hearing that they didn’t think their feedback would be taken seriously or they didn’t think it was worth submitting. There’s nothing I’d love more than to wake up tomorrow with tonnes of new emails in my inbox.

If you’re reading this post, please, go and submit a piece of feedback, even if you think you have nothing to say. Anything from a single sentence all the way up to an essay is welcome.

(For those that are interested, Google Docs stores the results in a spreadsheet. The only data gathered apart from what you supply is a timestamp of when you submitted the form.)

Meeting notes from today, for…

Meeting notes from today, for those who missed it (see also the IRC logs):

Response Objects (#33)
Response objects are on their way. Discussed how we handle WP_Error and whether we should implement a WP_JSON_Error. I’m in favour of the former, since it’s an existing paradigm in WP core, but WP_JSON_Error being a Response object would be nice. We’re going to loop back to this after the response object is merged.

User Endpoints (#20)
We’re going with read-only access for now, since the code is basically already written (for post authors). Write access will be established later, but this is a pretty low priority for now unless anyone wants to tackle it specifically.

Endpoints vs Routes vs ?
@mikeschinkel pointed out that the terminology here is a little confusing, since the permalink system has a concept of endpoints too. As it relates to the API though:

endpoint = code which supplies a response, route = map from HTTP to endpoint

We’ll probably want to revisit this for core merge and clarify it, but this matches the wider API community terminology.

Unit Testing (#6)
Strong consensus here that we need help setting up the infrastructure for unit testing. @ibaku might be able to help us out with this, otherwise I’m sending out the Batsignal to scribu and wonderboymusic to see if they can give us some pointers (as they both have familiarity with testing).

Theme Developers and Outreach
@rachelbaker pointed out that I didn’t really say how theme developers can help out, so I clarified:

Right, so WP API has a built-in JS API. I’d love for theme devs to take a look at that and see what it’s like using it in the wild
I know Tareq Hasan has written a proof-of-concept one:
I want to make sure wp-api.js is useful, and flesh it out with more methods as needed

@mzaweb noted we should see if the o2 team has any thoughts on this side of things, so hopefully @justin can help us with talking to them? Also noted that we should talk to the mobile team and get feedback from them, as well as the security team (in particular, mdawaffe) for feedback about authentication.

In short, lots of things to think about. This week’s release is all about OAuth (#32) and I’ll be pushing code up today for that, so we can start testing it. The OAuth stuff will be far from final, so feedback appreciated there too. Basic auth isn’t going anywhere just yet (#37 is scheduled for 1.0), so you can keep testing with that for now.

Just realised I forgot to…

Just realised I forgot to post this earlier, so apologies for the late notice. Just confirming, this week’s meeting is coming up in about 7 hours: Monday 2nd at 21:00 UTC (same time as always). There’s a few things I’d like to touch on, including:

Further agenda items welcomed 🙂

Also, if you missed it, 0.7 is out albeit slightly late (sorry!). Thanks to everyone who contributed to it!

Thanks to everyone who made…

Thanks to everyone who made it to the meeting today. Here’s what we discussed.

We’re aiming for OAuth 1.0a in core by version 1.0. Max Rice has an implementation in WooCommerce’s new API (based on WP API) that is pretty lightweight, so I’m happy to include something like that in core.

I’d like to aim for OAuth integration in 0.8 (next week’s release), and smooth it out as needed in 0.9 and 1.0.

OAuth might make development use harder, so basic authentication will likely stay around, but probably moved into a separate plugin for development use. For Javascript applications, an OAuth access token will be pre-issued via wp-api.js, and we’ll have to bake signing into that too. This shouldn’t be too much of a problem, fingers crossed.

Having API clients opens us up to cool things like client scope, however we’re going to look at this after 1.0 once the core part of this is complete. We also have to consider the WordPress apps for various platforms, so we may need to look at more things here.

Global State
At the moment, the various sub-parts of WP API (e.g. WP_API_Posts) rely on a bunch of global state via actions/filters. This could make it a pain for plugins to use the WP_JSON_Server class without modifying it. We talked about this, and it’s probably not as big of an issue as I expected, but I’ll get up a pull request about this soon.

Request/Response Objects
At the moment, all request parts are passed in via function parameters (yay!) but not all values are returned from the function (boo!); that is, our methods cause side-effects. Headers for example are sent via the server object, which makes it difficult to embed responses from endpoints into others without accidentally sending headers as well.

This is something that needs core team discussion as well, but the feeling here is that we want to push towards this, based on usage patterns both in this project and in others. I’ll begin talking about this with the core team to gauge their feelings on it, and we’ll see what everyone thinks of it.

Now, some meta notes: I’d…

Now, some meta notes: I’d like to welcome @rachelbaker and Aaron D. Campbell to the team!

I’d also like to announce that the team membership process is changing to an invitation process, based on contributions to the project. To coincide with this, it’s time to move to the next phase of this o2: open posting. As I noted in my original thoughts post, the discussion here was closed temporarily while we got familiar with the system. I think we’re all fairly well acquainted with the system now, so it’s time to open this up.

Comments are now open, but unfortunately, we can’t currently open posting up to everyone as from what I’ve been told, as doesn’t support automatically granting everyone contributor status. I’m working out what to do here, but suggestions are welcome if you have ideas. (The aim with this is to act similar to a mailing list, rather than an announcement blog.)

So, after a bit of…

So, after a bit of an extended hiatus, I’m back! 🙂 Thanks to @mordauk and @japh, we still got some work done on the project with a couple of pull requests being merged.

Let’s start planning the upcoming weeks. I’d like to push out one release per week, starting this Wednesday (with a break over the Christmas week), which gives us:

  • 0.7: November 27th
  • 0.8: December 4th
  • 0.9: December 11th
  • 1.0: December 18th
  • 1.1: January 1st

I’d like to have the core of the project complete by 1.0, then work on adding features (e.g. new endpoints) past that. 1.0 should be basically a ready-for-core version, and any core changes after that must have backwards compatibility. This should ensure that we can keep developing while also starting the process of merging into core. This should coincide nicely with 3.9-early.

To plan out what we need to tackle now, let’s schedule a meeting for Monday 25th at 21:00 UTC (Tuesday 26th at 7:00 AEST, Monday 25th at 16:00 EST, Monday 25th at 13:00 PST). (If you can’t make it, don’t worry, minutes and discussion will be posted here.)

Comments are closed for team…

Comments are closed for team discussion only, but comments are welcome via Twitter.

Since this is slated for being in core and is a pretty big project, do you think we could start to open it up more, with a more inclusive P2 and weekly IRC chats?