[wp-hackers] GSoC Proposal: JSON REST API

Sun Apr 14 21:49:16 UTC 2013

Apologies for the late reply.
@nacin ========Brother, I don't think the comparisons with previous year's GSOC is overly apt.The projects and people you mentioned all build features that could only be accessed from the admin area.The *RISK* if they were badly architected or insecure or buggy is/was limited.Given the current mass attack on Wordpress websites, I think it's not out with the realms of reason that some of us are concerned at something with a potentially huge impact on any/all WordPress sites is being proposed to be undertaken on a programme such as this.
As I said - it's not about WHO writes it. Ryan has been here longer than me, and is a much better developer than me (not that hard really). He's also a lovely fella who I enjoyed talking to about SimplePie and his other work at #wpcs. It's not a comment on Ryan - at all.
It's that a mini-project like this that has a far reaching impact with a potentially huge risk should not be undertaken to fit in with an arbitrary timescale decided upon by an independent external 3rd party. The merit of the proposal should be weighed up independent of the developer proposing it, as long as there is consensus that the developer is up to the challenge of the proposal should their be no external constraints.
Allow me to quote Kev's rule of Risk Management number #3: "Building a house on sand is still a bad idea even if you like the construction company".
(plus, and maybe it's just me, but isn't there a JSON API already available in jetpack http://jetpack.me/support/json-api/ via the already build REST API for WordPress http://developer.wordpress.com/docs/api/ )

@ Bryan========
> How can you know time is going to be an problem without even knowing what the scope of the project is?
Honestly? Years of project management.
Allow me to quote Kev's rule of Project Management number #3: "When someone says they want to build the Titanic in 3 weeks, you don't need to know how many lifeboats are in scope to know it ain't going to happen".

@Ryan=======
> That gives 65 days planning and 91 days working on the implementation.
I think this is a great example of the difference between a developer and a project manager.It is 91 days, you're right and I apologise. But actually, according to my calendar 91 days = 65 "working days".That is 65 working days if you do nothing but work on this every day. No school work, no day off, no client work, no family issues, no sick days, no days where the internet is down, no force majeure, no computer crashes, no days on simple pie, no holidays etc etc.

Thats why I'm able to come to a conclusion about it being too big.Because I already think you've over estimated how many days you have by 30% ;-)

Anyway, to each their own :)

> From: wp at andrewnacin.com
> Date: Sat, 13 Apr 2013 03:05:46 -0400
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] GSoC Proposal: JSON REST API
> 
> 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