Log in

No account? Create an account
LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Changes to the XML RPC API? [Apr. 22nd, 2006|11:17 pm]
LiveJournal Client Discussions


[mood |frustratedfrustrated]

How should I go about petitioning for some serious changes to the XML RPC API and documentation updates?

I'm wanting to set some good minimal standards here, such as facilitation of metadata editing, retrieve of properties like comments, and ensuring that there's consistent use of certain formats (getevents returns "eventime" as a member in the structure, but the "editevent" takes this as several argument fields abrievated all differently -- which is very frustrating). The XML RPC API looks like it was put together over a few months to support the bare minimum of the site, rather than providing a decent API for the clients.

I'd be hard pressed to write a good AJAX application on top of this API :/

[User Picture]From: int
2006-04-25 03:09 am (UTC)
Wondering how you'd write an AJAX application when you're posting to a separate server.
(Reply) (Thread)
[User Picture]From: silveryrose
2006-04-25 03:18 am (UTC)
In this case? You would post back to the originating server which would in turn proxy the request to livejournal.
(Reply) (Parent) (Thread)
[User Picture]From: jwm
2006-04-25 03:21 am (UTC)

I would suggest that it's more accurate to say that the xml-rpc interface is just a reimplementation of the older plain text protocol, which was solely designed to support posting clients. Fairly forward minded of LJ, given that it was put together over five years ago before anyone coined the term 'web 2.0', but in the current world, where every startup web app exports it's whole API from day one—yeah, it's a bit naff.

If you want to see real change on this, you'll probably need to ride the process all the way from building a spec to writing the code. Even if you don't do the lot yourself, you have to signal to all the stakeholders that you're serious about making the change happen, and aren't just another user grizzling to have someone else write them a feature for free.

I'd start by going fishing in this group, and others like greasemonkies and lj_dev to see what sort of problems people have with the current API, cook up a proposal and put it out to each of those groups for comments.

(Reply) (Thread)