Since WordPress is open source…

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?

25 responses to this post.

  1. I think you have a hammer. ;)

    Reply

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

    Reply

  3. I can see I’m not likely to get an answer to the question I asked. :-(

    Reply

  4. 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?

    Reply

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

    Reply

  6. In dotOpml.root, the XML-RPC code is in dotOpmlSuite.folderWatcher.

    Reply

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

    Reply

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

    Reply

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

    Reply

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

    Reply

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

    Reply

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

    Reply

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

    Reply

  14. LOL. It helps to have everyone smoke the same dope. Less conflict that way.

    Reply

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

    Reply

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

    Reply

  17. […] 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. […]

    Reply

  18. *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.

    Reply

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

    Reply

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

    Reply

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

    Reply

  22. Oh well, I see it works only on Macs and Windows. Good luck with the efforts!!

    Reply

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

    Reply

  24. 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?

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 60 other followers

%d bloggers like this: