[wp-hackers] GSoC Proposal: JSON REST API

[Andrew Nacin]

On Sat, Apr 13, 2013 at 1:41 AM, Mike Schinkel <mike at newclarity.net> wrote:

> On Apr 13, 2013, at 1:29 AM, Bryan Petty <bryan at ibaku.net> wrote:
> > So it would be really nice if everyone would stop speculating on *if*
> > a REST API project should be accepted for GSoC, and actually discuss
> > what *could* be possible as a GSoC project, and what you might like to
> > see out of such a project, assuming it was feasible and acceptable.
>
> Any API destined for core needs more time than GSOC, no matter how small
> you try to make the scope. So you are requesting that I stop objecting to
> the thing I am objecting to.


In order for a project to reach its second contributor, it must first have
one contributor. In order for a project to reach its third month, it must
be around for two months.

API development sometimes suffers from design by committee. It gets
over-engineered because there isn't a proper sense of priority, scope, and
direction. For the record, the menus system was the product of more than
six months of work — including some time spent as a WooThemes project — and
wasn't an example of schedule affecting architecture. It was an example of
architecture by committee. A large group of developers working to build
something with ill-defined scope and purpose (so much that an outside
project was brought in to provide a foundation and direction). Given those
parameters, we actually did a pretty good job. It wasn't an example of
under-engineering, it was an example of over-engineering. But I digress.

Saying that we shouldn't accept Ryan's proposal because two months isn't
enough time for an API "destined for core" is missing the point of
experimentation, of pursuing an idea, of trying something and seeing how
well it works. It also tramples a point Bryan has sought to make — the
project's proposal, scope, and schedule have yet to be fully discussed or
decided.

We're not going to take an API that Ryan built in a cave in two months and
drop it into core. You're crazy if you think we're going to rush something
of this magnitude. Rather, the architecture he comes up with, and the
decisions he makes in consultation with his mentors and the lead
developers, will jumpstart discussions, serve as a starting point, and be
an impetus for there to eventually be a proper core API.

GSoC is actually the *perfect* venue for something so big as this. Have a
single contributor be paid to do a ton of research, draw up a first draft,
and be in a position to spearhead core development in this area — it works,
and I have examples. Here are some previous Google Summer of Code projects
that had indelible impacts on WordPress, despite being one person + two
months.

***

In 2007, Dion Hulse did a project for a plugin upgrader. Early 2008, it
made its way into core and became a feature in 2.5. In 2008, Dion Hulse did
a project for a plugin installer. It, too, ended up in core, becoming a
feature in 2.7.

WordPress Core Developer Dion Hulse has since contributed the installer and
upgrader for themes, and the core upgrader. In the process, he also wrote
the Filesystem API, and largely shepherded the HTTP API.

In 2010, I proposed a new theme editor with revisions. It worked to some
extent, but was incredibly shaky mostly because our theme "API"
(get_themes() et al.) was insane. In 2012, as a core developer of WordPress
and using what I learned as a Summer of Code student, I rewrote the entire
API from scratch as WP_Theme. http://core.trac.wordpress.org/ticket/20103.

In 2009, Daryl Koopersmith attempted a WYSIWYG theme generator. Here's his
proposal: http://gsoc2009wp.wordpress.com/daryl-wysiwyg-theme-generator/.
Obviously something that would be great for core, and should not possibly
have been written by one guy in two months. Elastic Theme never left alpha
but it was a successful project because of what was learned.

The next year, Daryl Koopersmith proposed a visual CSS editor. (This was
jokingly considered Elastic Theme version 2.) It was a very ambitious
attempt that involved parsing out a CSS file and allowing it to be edited
on the fly, complete with a preview. (I'm over-simplifying — this was an
incredibly tough project.) It too never left alpha but it was a successful
project because of what was learned.

In 2012, WordPress Core Developer Daryl Koopersmith created the WordPress
customizer, and it shipped with WordPress 3.4. (Dare I suggest this was
Elastic Theme version 3?) It continues to change the way themes are
previewed and modified. Just look at what WordPress.com shipped last week:
http://en.blog.wordpress.com/2013/04/02/customization-made-simple/. Without
his two GSoC projects, Daryl wouldn't have had the knowledge to create such
an ambitious feature, nor would he have become hooked on WordPress and
contributed a few dozen other features, nor would he have become one of the
best JavaScript developers out there. (I also would have never met him, and
he would have never served as my best man. But I digress.)

***

It's entirely possible that what Ryan architects is absolutely amazing.
Now, I couldn't speculate whether we'd accept a project like this from
someone who is unknown to the WordPress project, but that's not the case.
He's been contributing to WordPress longer than I have (despite being more
than a few years younger than me) and has a strong track record, including
managing SimplePie and writing his own HTTP library. He also attended the
WordPress Community Summit in October, where he participated in a number of
API and architecture conversations with other leading contributors. (It's
worth noting that if we didn't accept unknown developers who proposed
ambitious projects, this community would be without two of its smartest
developers, Dion and Daryl.)

It's also entirely possible that what Ryan architects gets scrapped — but
not before we have five dozen decision points enumerated, one or more
design patterns written and tested, use cases researched, and plans drawn
up for how an API should be integrated into WordPress core. That's part of
the beauty of GSoC — Ryan will have contributed to the project in a
worthwhile way, and will have moved this effort forward. If you think I'm
not going to support a proposal from a strong, well-known developer to do
something like this, no matter the "destiny" of the API, you're crazy.

Mike, you've raised your objection a few times now. Consider it noted.

Nacin