[wp-hackers] GSoC Proposal: JSON REST API

Sat Apr 13 07:48:31 UTC 2013

Replied off-list.

-Mike

On Apr 13, 2013, at 3:05 AM, Andrew Nacin <wp at andrewnacin.com> wrote:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers