dw_dev | Protocols discussion

Somebody brought up the topic of Really Simple Discovery and the Metaweblog API in

dw_news, so now might be a good time to discuss protocols and our plans.

We currently have one bug to update the Atom publishing protocol and some bugs about updating our XML-RPC.

This is a post to collate discussion about:

1. What APIs do we currently support, and what state is our support for them in?
2. What APIs exist and what are their pros and cons? How popular are they with regards to services and clients that support them? How extensible are they, since we have unique posting metadata? Which ones would be a good fit to implement or improve? Where are good resources and documentation about them?
3. Where do we want to head with posting APIs, our overall goal?

Currently supported for posting

* Atom -- old version, needs upgrading desperately. We have a bug for this here. Once updated, we can start extending the protocol to support our custom features.
* Blogger -- had for a while, probably outdated.
* Flat API -- custom LJ flat API, destined for death.
* LJ XML-RPC -- custom LJ XML-RPC API, might be destined for death if we can adequately extend Atom

Current supported and not supported data stuff

* FOAF -- http://foxfirefey.livejournal.com/data/foaf
* Interests data -- http://www.dreamwidth.org/misc/interestdata.bml?user=foxfirefey
* OPML -- http://www.dreamwidth.org/tools/opml.bml?user=foxfirefey
* Icon data -- http://foxfirefey.dreamwidth.org/data/userpics
* Fdata -- Don't have this yet and whether we will is still up in the air; discussion on this here; issues include whether or not we are showing data that isn't shown on the profile

Flat | Top-Level Comments Only

I'm right there with you for standards compliance for interoperability.

It permits me to login to and use DW from my favorite web browser, which is Lynx (with SSL support).
Simplicity would be another and I've been seeing that in the subtle changes from LJ to DW code. :0)
XML can result in some gorram serious markup bloat and I'd stay away from it in terms of an API.

Above all, simplicity and interoperability for me, please.

/\__/\
(='.'=)
(")_(")

Music: God is an Astronaut - Remembrance Day

Edited 2009-06-27 23:14 (UTC)

As far as I know, every single major API I know of is XML based--that includes Atom, Metaweblog, Blogger's, WordPress's and Movable Type's.

Don't mind me. I'm just and old command-line junkie from back in the day.

Well, time for me to crawl out from my Unix shell and get with the times.

Please keep it as simple and as "lightweight" as you can.

What I'm seeing in terms of a "front-end" web developer are lots (and maybe lots more) of people using tablet and mobile devices that will call for simpler and "lighter" interfaces.

Music: Snow Patrol - Lifeboats

Edited 2009-06-28 00:16 (UTC)

There are definitely improvements for making things lighter. For instance, there is a bug for adding handheld stylesheet support to the core of S2--that would mean that handhelds that supported using that stylesheet would use it instead of the regular one.

Coolness to the ghoulness!

I'd assumed that DW development folk would have something like in the works, but that we're still pretty new at making noise on port 80 and working out bugs and stuff, I didn't want to make a lot of noise about a handheld/mobile interface.

The main thing is to get (and keep) DW stable. I'm not about a lot of fancy doo-dads and whatnots, but rather a smaller set of features that work and can be depended upon to do so.

As long as DW remains advertising- and corporate-free, I'd like to contribute to DW development and maintenance as a volunteer. I know my way around a Unix shell and not too shabby at hacking HTML and XHTML with a propensity for doing away with unnecessary markup.

Like most g33ks of my generation, I can teach myself how to do things when pointed to the right documentation (read, "man page"). Is there anything that would be helpful for me to learn in order to become a DW volunteer?

Music: firefly theme music

It sounds like some of your concerns align with the accessibility group--I'd check out

dw_accessibility with that in mind. The things that concern accessibility are generally the things that also make pages accessible in screen readers!

We have a list of current accessibility bugs here and

dw_dev_training can be a touchstone for starting development. There is a Getting Started wiki page as well.

Are you handy with CSS at all? Once handheld stylesheet abilities are added to the core, I think we'll be needing handheld stylesheets for the current 3 styles--Negatives, Zesty, and Tabula Rasa.

the "flat" protocol isn't. it's pretty awful but is widely supported by clients, including logjam, which is probably the most widely used client on gnu/linux.

LJ's flat protocol isn't a major API, though--I'm talking about APIs used by more than one service. It's one of LJ's main APIs, but it's not going to help us much. Any client that implements LJ's flat protocol would end up having to do a custom implementation of our flat protocol, because we'd have to change and update parts of it anyway with the WTF split.

Doesn't ljlogin use the LJ flat protocol when it logs in/out? No flat protocol on DW would mean no ljlogin on DW.

Protocols discussion

Currently supported for posting

Other posting APIs

Current supported and not supported data stuff

standards compliance for interoperability

Re: standards compliance for interoperability

that's what I was afraid of

Re: that's what I was afraid of

adding handheld stylesheet support

Re: adding handheld stylesheet support

Re: standards compliance for interoperability

Re: standards compliance for interoperability

Re: standards compliance for interoperability