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.)

Hi everyone, sorry for being…

Hi everyone, sorry for being inactive recently. I thought I’d give you a heads up that I’ll be mostly offline for the next two weeks as I do final exams. This is also the reason for my inactivity in the past few weeks, and I’d like to apologise for this. I’ll be back to being active from the 13th onwards.

You may have noticed today that I moved the repo to WP-API/WP-API, and I’ve added everyone to the Contributors team. This allows assigning you guys as owners of tickets, while still keeping pushing privileges separate. It also emphasises that the project is no longer just mine. 🙂 I’ve also moved the auxiliary projects (the reference client and multisite addon plugin) to the organisation. (This means you should also be able to track all issues at once via the organisation issues page.)

I’ve also gone ahead and merged all of the pull requests that we had open. I’ve given push access to @japh and @mordauk to merge in bug fixes and small feature additions, while any bigger changes can wait until we’re back to having weekly IRC meetings again. I’m aiming for a 0.7 release on the 13th with all the changes so far (and any new ones), after which we’ll go back to weekly releases and meetings.

If you’ve got any comments, I’m around for a bit, and I’ll be available via email for anything urgent.

Alright, after a short break…

Alright, after a short break on my behalf, let’s start getting you guys set up to contribute. The model I’d like to use for managing the project is the same one I use for most of my projects; that is, groups of changes always go in pull requests. If you’ve contributed to wp-cli, you’ll know what I mean. In a nutshell:

  • Fork the main project on GitHub
  • For a new feature, create a new branch locally and commit to that branch
  • Create a pull request (or attach your branch to an existing issue if possible)
  • I’ll review and merge

With the exception of major features, I’ll merge everyone’s pull requests as soon as possible. Non-team contributions will need sign off by at least one team member (ideally not me, to ensure there’s a few people checking), while team contributions will be merged basically straight away.

In the case of major features, file a pull request and then post here for discussion. Major features will need a rough consensus to get in, plus sign off from the team leader (hey, that’s me!).

Why am I not just giving you all commit access? For accountability reasons (especially since this is aimed at going into core), I’d like to make sure every change is signed off by myself. (One committer for the team seems the right sort of scale, since even with the size of core, it only has a handful of committers. Unlike core though, I want to move fast. :)) Rest assured that I’ll be proactive about merging your code.

Why are we not using Trac for issue tracking? Core Trac isn’t really the right place for this at the moment (but it will be eventually as we merge in), and the GSOC Trac isn’t really a great place for this either, since GSOC is over now.

As an example, I filed two enhancements, and @mordauk filed a bug fix as a pull request.

I finally got around to…

I finally got around to publishing my post on the development process that I’m looking to try and use here, so I’d recommend having a read of the post. I think we’re off to a fairly good start already, so thanks for being awesome so far. 🙂

Heads up: no team meeting…

Heads up: no team meeting this week, but I’ll be publishing a blog post on some process and meta issues instead. Does anyone have anything they’d like to raise in lieu of the meeting?

At the meeting this morning,…

At the meeting this morning, I articulated some of my thoughts about this o2 and what it’s meant to be. Basically, IRC meetings are typically horrible, and make/core is more of a blog, so this is intended to fill the gap and act as a home for discussion. (Imagine it as a sort of mailing list.) The less we can worry about making it to a meeting on time, the more we can worry about getting the job done. (Don’t worry though, I’ll be available for office hours on IRC every week at this time.) Along those lines, please post whenever you have a question, idea, or something general to discuss.

So, now for that discussion. Summer of Code officially ended today, so I can start giving you commit access to the project. I’ll get that set up in the next week or so and mention the best way for development to work. Out of interest, who’s familiar with git, and/or who would prefer to use Subversion?

We also need to discuss authentication. At the moment, the API only supports Basic authentication. The idea here was to implement the most basic thing that would work, and leave everything else to plugins. From the feedback I’ve had though, this might not be enough, and implementing some sort of token-based authentication might be needed. I’m hesitant to do this, given the size of the code needed to deal with it, so I’d love to hear your thoughts on it.

I also have a collection…

I also have a collection of random thoughts about items we might need to look at.

  • Mobile team meetings: The next mobile team meeting is on Monday 24th at 16:00 UTC; can anyone make it there? I’d love to hear feedback from them and ensure they’re involved as much as possible, as they’ll be one of the big consumers of the API.
  • Beginning core integration: The API has a bunch of functions that are basically transforming internal data into external, serialisable data, and vice versa. These aren’t particularly specific to the API (and in fact, I’m sure wp-cli would love these), so they’re prime candidates for initial integration into core. Likewise for various helper functions (datetime handling is a big one there).
  • Front-end Editor: One of the other Features as Plugins is a Front-end Editor. This is still in the “investigating” phase right now, but I’ve suggested that it’d be a great candidate for using the API. I don’t want to hold up other teams pending our work, but seems like it could be a good place to work together.
  • Twenty Fifteen? Aiming for integration in Q1 2014, we might want to start thinking long term about pushing theme developers towards using the API for more interactive themes. A core theme based on the API would be great for this.

I’ll be making a post…

I’ll be making a post on make/core shortly summarising what I’ve done in the past week, but figured I’d give you guys the scoop. Along with some CPT-related stuff, I’ve spent the past week reworking the documentation for the plugin and I’d love to hear your feedback on it. For any of you who haven’t had a chance to mess with the API yet, I’d be interested to hear what you think of the documentation, and if there’s anything in there we can start to improve on.

As a reminder, our next meeting is on Monday 23rd at 21:00 UTC (Tuesday 07:00 AEST, Monday 17:00 EST, Monday 14:00 PST). Plan for this week is for me to start working on getting you guys set up to start hacking, discuss options and meta, and make a decision on authentication. Again, let me know if you’ve got any ideas for the agenda for this week.