Ben Trott: I've released XML::Atom, a Perl implementation
of all things Atom. The goal for XML::Atom is to provide an
implementation of the syndication feed format, the API, and the
archiving format planned for Atom. Currently, it provides support
for the feed format, and an implementation of a client for the
Cool! Some ideas for a 0.03 version:
Comment support. Instead of introspection, look
for a link tag. See description on
site. On my site, authorization is not required to post a
comment, but author information (name and url or email) is
Wiki support. Instead of POSTing a comment, how
about PUTing a page? If it is a new version of a page, the
modified element must match. I would be willing to create a
test wiki based on moin-moin, one where authorization is
P.S. Instead of calling the API createEntry, why not
simply call it post?
At what point was a well defined comment determined in the Atom wiki? Could you provide a link to that discussion?
When I was active in this endeavor, I recall that a great deal of time and effort was spent on what is a well formed post. I never saw or read about such a discussion for comments.
So let's see: XML::Atom 0.01 supported Atom-digest, which allows both client and server to verify to each other that they know the user's password, but does not require either client or server to store that password in plaintext. 0.02 replaces this with WSSE, which offers no verification that the server you think you're talking to actually knows the password (and could therefore easily be spoofed), and requires both client and server to store the password in plaintext.
WSSE Username Token Digest doesn't require you to store the password in plain text.
One could argue that Atom-digest required you to store the password in exactly the format that Atom-digest specified. Already have a bunch of passwords that are not stored in that format? If so, then you are screwed.
Tim, it was posted on my weblog because it was something that I have speculatively implemented. And also in an attempt to give the topic a wider visibility, mainly because some people have chosen not to participate in that venue.
Any vendor that implements a draft standard faces this issue. Whether he is wasting his time or not depends on how much his customers value the provided functionality and how he plans to migrate his users when the final version is released.
Vendors have to figure out how to strike the right balance between implementing a draft standard as it is being designed so they can provide implementation feedback as well as be quick to market while not tying their products to a technology before it matures
Ben Trott: I've released XML::Atom, a Perl implementation of all things Atom. The goal for XML::Atom is to provide an implementation of the syndication feed format, the API, and the archiving format planned for Atom. Currently, it provides support...