foxfirefey (
foxfirefey) wrote in
dw_dev2009-06-27 03:37 pm
Entry tags:
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?
* 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
* Metaweblog -- this seems to be very popular as well. Apparently del.icio.us uses it to do auto-links-posting, for instance.
* RDS -- Really Simple Discovery -- this seems to be a generalized way to let clients know what protocols we support
* 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
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
Other posting APIs
* Metaweblog -- this seems to be very popular as well. Apparently del.icio.us uses it to do auto-links-posting, for instance.
* RDS -- Really Simple Discovery -- this seems to be a generalized way to let clients know what protocols we support
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

no subject
1) Custom "flat" protocol mode, which is LJ specific, and should die.
2) Custom "XML-RPC" protocol mode, which is LJ specific, and should die.
3) Export comments XML feed, also LJ specific, death would be too good.
4) Export your journal as XML on the web site. WTF?
5) FOAF data for some profile information.
6) RSS 2.0 (I think) data for the journal feeds.
7) Atom (old old old) data for the journal feeds, as well as for writing posts.
8) fdata, intdata, etc?
I am sure we have some other ways of getting data out of the site. Feel free to point out any that I have missed, so we know precisely where to put the scalpel.
As to where we want to go? #1, I want standards compliance for interoperability. I want other sites to be able to access our data, and for us to be able to access theirs. If this means that we will drop the flat and XML-RPC protocols in favor of implementing (and extending as necessary) Atom, then that's what we should do.
I don't know what the state of the art is on protocols. That sounds like something that a guy like David Recordon would know, maybe we can ping him and get a summary. Or someone can do some leg work and research the various states-of-the-art.
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
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)