fu: Supporting Atom Publishing Protocol

fu (

fu) wrote,
@ 2011-01-11 12:54 am UTC

Supporting Atom Publishing Protocol

I've been working on updating our implementation of the Atom Publishing Protocol for Bug 852, and I have a patch up there now.

Have several longish comments, but the short version is that our implementation was old to the point where I don't think any clients could use it, so I have felt free to break the old URLs while updating our implementation.

That is, I've removed support for:
http://www.dreamwidth.org/interface/atomapi/username/* (completely broken;
username had no effect on which journal the interface would use)
http://www.dreamwidth.org/interface/atom/feed
http://www.dreamwidth.org/interface/atom/post
http://www.dreamwidth.org/interface/atom/...

And I've implemented a new interface:

http://www.dreamwidth.org/interface/atom
GET: service document / used to discover the APP URLs we provide

http://www.dreamwidth.org/interface/entries
GET : lists the entries
POST: makes a new entry

http://www.dreamwidth.org/interface/entries/tags
GET: lists the journal's tags

http://www.dreamwidth.org/interface/entries/123
GET: retrieves entry 123
PUT: edits entry 123
DELETE: deletes entry 123

Does anyone have any concrete reasons I shouldn't push forward with this?

Also, any suggestions for how / whether to support posting to communities? What URL should we use? :-)

(23 comments) - (Post a new comment)
(Flat) (Top-level comments only)

no subject

matgb
2011-01-10 05:05 pm UTC (link)

Second set of URLs has some broken code , I think it's a missing " in the cut text.

Definitely need to support posting to comms, but client protocol stuff is completely beyond me (trying to learn it though, in the process of updating Delicious Glue, simple enough for a newbie to get working, only, well, I can't do anything beyond the basics). Essentially, if a client won't let me post to a comm, it's not a client I can use. And I'm not a heavy Comm user.

(Reply to this) (Thread) (Hide 6 comments) (Show 6 comments)

no subject

fu
2011-01-10 05:17 pm UTC (link)

Thanks, fixed!

And I can take care of the backend stuff, but trying to figure out a "nice" way to present it in terms of URLs -- perhaps

http://www.dreamwidth.org/interface/atom/entries (personal journal)
http://www.dreamwidth.org/interface/atom/afuna/entries (also personal journal)
http://www.dreamwidth.org/interface/atom/communityname/entries (some comm communityname)?

(Reply to this) (Thread from start) (Parent) (Thread) (Hide 5 comments) (Show 5 comments)

no subject

matgb
2011-01-10 05:21 pm UTC (link)

I would say the latter two work to be consistent, the former might be a good shortcut, but could be confusing, especially for client authors that aren't normally DW users?

On most other platforms that I know of, username and blogname are always separate, so having a shortcut for people posting to just their journal may confuse those used to those standards.

But, given my complete lack of knowledge of this field, I don't know.

(Reply to this) (Thread from start) (Parent)

no subject

matgb
2011-01-10 05:40 pm UTC (link)

Thought occurs. Why not put them on the subdomains themselves?

matgb.dreamwidth.org/interface/atom/entries

Is that possible or would it require too much duplication/redirecting?

Or does ATOM include auto detection in some way? I'm partially thinking mid term, if/when we get domain mapping setup, there will be some that'll make their setup appear completely separate from DW.

(Reply to this) (Thread from start) (Parent) (Thread) (Hide 3 comments) (Show 3 comments)

no subject

fu
2011-01-11 04:12 am UTC (link)

The way it is coded right now, it would be the work of a few lines to change, and no redirects *g*

I need to think about the security implications though; maybe post to dw-dev as well. The big problem with domain cookies is that we generally keep as much as possible out of that space, so that if someone steals your domain-specific cookie (but not your master cookie), they can't make you do stuff to that journal.

This may not be an applicable concern since we use WSSE and/or digest auth for these.

But well, frankly I don't know enough off the top of my head to say with any certainty, so I'll want to look into it first.

And yes, there's auto detection. The service document lists available collections you can manipulate (edit, etc), which includes all the relevant links that you should need.

(Reply to this) (Thread from start) (Parent) (Thread) (Hide 2 comments) (Show 2 comments)

	no subject mark 2011-01-12 06:55 am UTC (link)
	I am 100% for "username.dreamwidth.org/interface/atom" ... that's what we use for everything else, right? (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	no subject fu 2011-01-13 12:22 pm UTC (link)
	Hmm, we use it for everything else that's display related, but not for anything that requires further action. I do like the subdomain for the atom interface though, and the only thing I want to make sure of is that we're clear on potential security-related issues! (Reply to this) (Thread from start) (Parent)

	no subject allen 2011-01-10 10:21 pm UTC (link)
	Just so you know, the completely out of date Atom implementation is why bug 2296 drove me crazy enough to have to take a break from DW coding. So thanks for tackling this. (Reply to this) (Thread) (Hide 3 comments) (Show 3 comments)

	no subject sophie 2011-01-10 11:38 pm UTC (link)
	Will the Dreamhack machine need any updates for this? I noticed that you were talking about an outdated version of XML::Atom in the bug. (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	no subject fu 2011-01-11 04:06 am UTC (link)
	checks Hmm, maybe. I have only tested with version 0.34, though from looking at the changelogs, up to say 0.32 is still okay. I don't know about 0.25 which is what the 'hack has, though. Can you see about raising it to either 0.32 or 0.34? (Reply to this) (Thread from start) (Parent)

	no subject fu 2011-01-11 04:07 am UTC (link)
	Unexpected bonus, but I'll take it! g (Hi) (Reply to this) (Thread from start) (Parent)

	no subject whump 2011-01-12 09:11 am UTC (link)
	Hi, I've been underwater lately and had not had time to follow up. First, thank you for taking on this ticket! Second, what do you need from me on testing? (Reply to this) (Thread) (Hide 2 comments) (Show 2 comments)

no subject

fu
2011-01-14 01:21 pm UTC (link)

Oh awesome, I was hoping you'd show up. Right now, I'm trying to work out some last minute kinks that are preventing me from being able to set up a publicly accesible testing environment for the API, but once we have that set up, would you be willing to poke at it with whatever client it is you use that supports APP?

I've worked with the documentation that I've found, and there's quite a lot of it, but having some data from with real-world clients, especially by users who (unlike me hah) aren't making assumptions about the responses received from DW, would be truly amazing.

(Reply to this) (Thread from start) (Parent)

	no subject fu 2011-01-21 07:01 am UTC (link)
	I have set up a public dev environment here: http://www.afuna.dreamhack.afunamatata.com/ You can create a test account and play around with the atom protocol there -- let me know how it goes! (Offer also open to anyone else watching this thread who's interested) (Reply to this) (Thread from start) (Parent)

no subject

pauamma
2011-01-20 11:19 pm UTC (link)

If using user-domain URLs for the service document, the username would have to be "who I'm posting *as*", since the document lets the client know what they can post *to*. Thus, the username would be redundant with the authentication credentials and would also require configuring per-account service documents (even if you only have one account, you can't rely on the client knowing out of the box that the service document for Dreamwidth is http://www.dreamwidth.org/mumble - you have to tell it the URL of the service document for post-as account "pauamma"). When you add people with multiple accounts, it only gets more tedious. So I would use www. for the service document.

Now the collections listed in the service document can have user-domain URLs - and in fact should, because they're just an Atom feed for the collection, just like the one used for syndication. But what the exact URLs shouldn't matter IMO, because a conformant client would just get them by retrieving the servce document, and not by using any programmed-in notion of what the collection URLs (and resource URLs) for Dreamwidth (Or any DW clone, or LJ clone) would look like. In fact, there's no reason to believe that they will remain unchanged as time goes on...

Another point worth keeping in mind for the future: the APP lets clients create media resources (which could conceivably be icons or pictures in whchever photo album thingy ends up having, or collections of links, for DW's memories/favorites/whatever feature). However, it also allows in-place modification, which requires a stable-across-revisions URLs. This doesn't fit the current URL scheme for icons (or the LJ/ScrapbookURL scheme for pictures), and any use of the APP for those features would have to deal with that.

(Reply to this) (Thread) (Hide 5 comments) (Show 5 comments)

	no subject fu 2011-01-21 02:30 am UTC (link)
	Hmmm, okay so you're suggesting www. for service URLs, and user-domain for collections. Then we return in the service document the collections for the entries of the user's journal and all the communities they can post to? (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	no subject pauamma 2011-01-21 03:24 pm UTC (link)
	Basically, yes. (Reply to this) (Thread from start) (Parent)

	no subject fu 2011-01-21 06:23 am UTC (link)
	Thinking about it more -- I think it depends on whether we want to think of each journal as a separate service, or if we want to put together all the journals that someone can post to. (Reply to this) (Thread from start) (Parent) (Thread) (Hide 2 comments) (Show 2 comments)

	no subject pauamma 2011-01-21 03:32 pm UTC (link)
	I would favor the latter approach. In addition to making it easier for clients to have a "post entry to" dropdown like the web update page does, it would allow future extensions to add "community userpics" as a collection for each comm the user miantains. (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	no subject fu 2011-01-25 09:27 am UTC (link)
	I like this idea and am beginning to talk myself into it. Have posted to dw-dev for any additional insights, but if no one protests or points out anything that makes it a bad idea, I will probably go this way! (Thank you g) (Reply to this) (Thread from start) (Parent)

no subject

faithofone
2011-01-27 03:33 am UTC (link)

Please forgive me if this comment makes no sense, I'm completely uneducated about how the whole atom thing works.

Right now, I'm using the atom api with Loudtwitter to post my twitter digests. The URL that I'm using is http://www.dreamwidth.org/interface/atom/post

If you're removing that URL, it'll break my twitter syndication, and it would be sad making.

(Reply to this) (Thread) (Hide 2 comments) (Show 2 comments)

	no subject fu 2011-01-30 01:12 pm UTC (link)
	Thank you for the reminder, and sorry for the belated reply, I couldn't get online until now. I will test this against LoudTwitter, and do what it takes to prevent this setup from breaking! (Reply to this) (Thread from start) (Parent) (Thread) (Hide 1 comment) (Show 1 comment)

	no subject faithofone 2011-01-30 06:37 pm UTC (link)
	No need to be sorry about taking a few days, we all do that occasionally. Thank you for taking the time to reply. I appreciate your work to ensure that I can still spam my friends with tweets. (Reply to this) (Thread from start) (Parent)

(23 comments) - (Post a new comment)
(Flat) (Top-level comments only)

Account name:	Log in with OpenID?
Password:	Forget your password?
	Remember me