I sent an email to Matt Mullenweg the other day and then I realized I sent it to the wrong place. It should be posted publicly so anyone who knows how to work on WordPress and can write production-level code, high enough quality so it could be included in the main distribution, could see it.
Here’s what I wrote to Matt.
| Matt, following up on our conversation on Thurs, I’m interested in developing a strong connection betw the OPML Editor and WordPress. |
| Here’s how it works — there are lots of elements of a weblog that are editable by outlines. The hierarchy of categories, blogroll, templates, blog posts, the about page, all can be edited as outlines. The blogging tool built into the editor already has these connections, implemented with a very simple back-end. It’s not actually very much work, even though it may seem it is, and in fact the architecture would simplify your code (I’ve written five or six blogging tools over the years). |
| I’d like to phase out of running a back-end. I can’t do the development in WordPress, but I am happy to provide guidance… |
So what do you think?
Scripting News Annex 
Posted by Bob Lee on January 24, 2006 at 6:04 pm
I think you have a hammer. 😉
Posted by Garrick Van Buren on January 24, 2006 at 6:18 pm
I’d like WordPress to have an OPML feed in the same way it has RSS feeds. I could probably whip something up – just haven’t dug into it yet.
Posted by Dave Winer on January 24, 2006 at 6:19 pm
I can see I’m not likely to get an answer to the question I asked. 😦
Posted by Matt Terenzio on January 24, 2006 at 6:34 pm
When you say the blogging tool of the editor “has these connections”, what does that mean? I’d be willing to contribute PHP code on the WordPress side, but what would the coupling be? XML-RPC? Or something tighter?
In other words, how would you expose those connections?
Posted by Dave Winer on January 24, 2006 at 6:54 pm
Matt, thanks for asking.
it’s all XML-RPC, and there’s not much to it.
Basically, each blog is a folder that’s on the user’s hard disk, and kept in synch with a parallel folder structure on the server. The blogroll is a file named blogroll.opml in the “decorations” folder. The header graphic is in the same folder, in a file called headerGraphic.jpg or headerGraphic.gif. (WordPress doesn’t seem to have the concept of a header graphic.)
Almost any OPML Editor user could work with a WordPress coder on these conventions. I’m willing to write the docs for the XML-RPC calls that keep the folders synchronized, although I would be happy to delegate that as well. 🙂
It’s all documented in the source code, in dotOpml.root (that’s a guidepost for a geekish OPML Editor user, not a WordPress developer).
Posted by Dave Winer on January 24, 2006 at 6:55 pm
In dotOpml.root, the XML-RPC code is in dotOpmlSuite.folderWatcher.
Posted by Wm. Marks on January 24, 2006 at 7:04 pm
I think there’s a certain sort of project that attracts 95% of open source contributors. I’m too lazy to characterize it, but it seems to do a lot with language and replication of features of other programs. (Cf. most sourceforge projects.) Not that it’s a bad thing. But this OPML project doesn’t seem to attract that kind of crowd.
Posted by Dave Winer on January 24, 2006 at 7:27 pm
I don’t want 95%, I want one programmer who likes to work with really smart users and who would place some value on my reciprocation.
Posted by David Brown on January 24, 2006 at 7:28 pm
I suspect that the coupling is XML-RPC. I don’t know why you’d want to get any tighter than that.
I think it’s a fantastic idea — WordPress is a nice open source backend, and the OPML editor is a nice open source frontend. Seems obvious to me that they should work together. In fact, when Dave first released the blogging capability for OPML, my first thought was that I wished I could use it with WordPress.
It may in fact be a hammer, a finely crafted hammer with an excellent pedigree. Nothing wrong with that. I do understand the “if all you have is a hammer…” reference… and I would counter with the comment that sometimes if it looks like a nail, it really IS a nail.
Hammer away, guys.
Posted by Dave Winer on January 24, 2006 at 7:36 pm
About the hammer comment, they said the same kind of stuff (only worse) about RSS, and it’s turned into R$$ since then, so eat my shorts, okay.
Posted by Sam D on January 24, 2006 at 8:35 pm
Man Dave,
I wish I wasn’t so busy, I’d love to get this working with you (I’ve become a php nut, like I used to dig into frontier) I’m going to send some notes to some people who might be able (and have the time to help) but might not have you on their radar)
Posted by Robert Sayre on January 24, 2006 at 9:38 pm
I think Dave Winer is absolutely right. In fact, there are lots of permissions and configurations systems that work exactly this way. They usually have obtuse WebDAV interfaces, but they do work. An OPML interface would work equally well but be easier to understand an implement. I’ve proposed essentially the same system to the Atompub WG and had it rejected.
To be perfectly honest, I feel there would be some Dave-specific waffling and angst. But, it would work, and it’s the right idea with a minumum of BS.
Posted by Robert Sayre on January 24, 2006 at 9:49 pm
Oh, and Dave, I know plenty about editing protocols, XML, OPML, RSS, and blogging systems, and I can code production-quality code in any scripting language. But, I still have no idea what the OPML Editor protocol would look like. Maybe you should document it a little bit, at your customary level of detail (which I think would be the perfect level, to clarify).
Posted by Don Park on January 25, 2006 at 1:06 am
LOL. It helps to have everyone smoke the same dope. Less conflict that way.
Posted by Danny on January 25, 2006 at 3:33 am
Don, you don’t have to smoke the same dope to avoid confict – OPML over XML-RPC is something I never personally want to inhale. But increased interop is inherently a good thing, and that’s present in what Dave’s asking.
Ok, so I’d suggest looking at this a bit more creatively. Playing nicely interop is best achieved by working to standards and/or other people’s system setup. Rather than having to ask the developer of a system like WordPress to modify their tool to support your tool, you could simply support their tool with yours. This is in line with the generally accepted notion that a “not invented here” attitude is net-net counterproductive.
So how can what you’re suggesting be achieved with a light touch? Working directly to the relational backend isn’t web-friendly, it’s better to go with exposed interfaces. Let’s assume that WordPress already had an XML+HTTP based interface to all the editable features. Some low-level protocol translation might be needed to whatever’s available, but e.g. bridging between XML-RPC and simple doc/literal communication isn’t difficult. Translating between different XML formats isn’t difficult either – if you could add XSLT support to the OPML Editor the world would be your oyster. But even if you do this development at the OPML Editor end, you’ll need to be clear about how to express the different kinds of data in OPML. As Robert suggests, if you want other people to work on this then you’ll at least have to document what you have in mind.
Alternately you could work on supporting the APP in the OPML Editor, and encouraging other developers to do likewise. That will cover all the aspects you described – categories, blogroll, templates etc. and will offer a common standard, saving yourself a lot of work on bending OPML to fit the job.
Posted by Dave Winer on January 25, 2006 at 5:25 am
Sam Devore was on the right track. If there are any people around who know the WordPress source, please get in touch at dave dot winer at gmail dot com.
Posted by Dave’s Wordpress Blog » Dan Gillmor’s story on January 25, 2006 at 7:12 am
[…] There’s been a lot of discussion about this. It’s good that he told the story after the fact, but it’s too late to do anything to help. What if Dan had been blogging the process as he was going along. Yes, people would have taken shots at it, that’s always going to happen (you can see that in my proposal yesterday to create a connection between two promising open source projects). But, people who might have partnered with Dan’s company who didn’t know what they were doing might have had their creativity activated. To me it was a puzzle what Dan was doing. Too bad we couldn’t participate in the process while it still was a process. […]
Posted by John Handelaar on January 25, 2006 at 9:53 am
*If* I understand this correctly, Dave wants more xmlrpc calls available and exposed in WordPress’s xmlrpc interface.
What I suggest you do is list them, and list what behaviour you expect – input and output.
Then whoever wants to implement them can do so – not only for WP, but also for (eg) Drupal, which exposes RPC calls in the same manner, and/or anything similar.
Posted by John Handelaar on January 25, 2006 at 9:54 am
Oh, I forgot – I’m pretty sure that extending the interface like that can be achieved with a plugin without touching the core code for WP. Certainly that’s how Drupal works.
Posted by ubuntonista on January 25, 2006 at 9:56 am
Dave,
What is the OPML editor?
I suppose you should have added links to the OPML Editor, as well as to any documented features/interfaces in the post when asking for help with something in this manner.
What is obvious to you might not be so obvious to the casual coder. 🙂
Posted by Dean on January 25, 2006 at 11:20 am
I can’t wait for this to take off. So Ubuntonista- OPML Editor can be found at http://support.opml.org/download with all the information about the docs and stuff on that page. I’m not a developer, but I’m a OPML user, and am willing to be involved in the process however I am able.
Posted by ubuntonista on January 25, 2006 at 1:05 pm
Oh well, I see it works only on Macs and Windows. Good luck with the efforts!!
Posted by myelin on January 25, 2006 at 1:55 pm
Echoing one of the above comments, you should be able to do this in a plugin. WP plugins can do pretty much anything. I don’t know if there’s a convenient way to add XML-RPC handlers to the system so you can call them via xmlrpc.php, but you could always add your own xmlrpc script (it would show up in http://(site_root)/wp-content/plugins/OpmlEditor/xmlrpc.php, where http://(site_root)/xmlrpc.php is the ordinary endpoint).
Your comment at 6.45pm suggests that you want WordPress to support the OPML Community Server’s XML-RPC API – is that correct?
There’s no way you’ll get WordPress to take on an OPML Editor dependency, but you can certainly do the following in a plugin:
– output the WP blogroll as OPML and rebuild the WP blogroll from an OPML file,
– likewise with categories,
– do anything you like with posts (although presumably wordPress.root already does this).
I’m kinda busy at the moment with work, but I’d be happy to help out in the role of somebody who has implemented the server side of the OPML Editor’s XML-RPC API (see opml.myelin.co.nz) and knows his way around WordPress (see structuredblogging.org), connecting concepts together and maybe writing bits of code.
Cheers,
Phil
Posted by eteraz on January 25, 2006 at 5:50 pm
If I want to know what the heck you guys are talking about where do I start?
Posted by Dave Winer on January 25, 2006 at 6:59 pm
The discussion gets more specific here…
https://scripting.wordpress.com/2006/01/25/getting-started-with-opml-support-for-wp/
Dave