The Wiki edit model more closely corresponds to using HTTP PUT
for creating new pages. In other words, the client determines
the URL. Some webloginging systems support this, though more
commonly the server determines the URL. However, I do expect
that having the client specifying the URL will become more common
with photoblogs and other mechanisms involving images. I
suspect that some additional information should be added to the
introspection file so that clients can determine server policies
and capabilities in this reguard.
MoinMoin inserts a hidden "datestamp" form field on HTTP POST
to ensure that people don't overwrite each other's changes. I
believe that other wiki software employs similar tactics.
What this would correspond to in Atom is requiring that the
atom:modified date be echoed back on the POST request. If it
doesn't match, the request is rejected. This should be
spelled out in the API.
This is fairly obvious, but needs to be spelled out: the syntax
for editing Wikis not the syntax used for display. This means
that there needs to be separate mechanisms for retrieving either
the original source vs the formatted source. This can be
achieved as simply as having different URLs for each
function.
All in all, not insurmountable issues.
"The Wiki edit model more closely corresponds to using HTTP PUT for creating new pages."
I disagree. Most Wikis I have seen work by turning camel cased words into links, which you can then GET to retrieve a default templated page, which you can then edit and POST back to update. This can be mirrored in the AtomAPI by GETting the Atom representation of a page, editing the 'content' and then PUTting it back.
Note that this flow also fixes the problem you point out with MoinMoin inserting a hidden datastamp. If you do a GET first, and then edit the 'content' and PUT it back, the 'datestamp' goes along for the ride. It should be noted in the spec that elements or attributes in an Atom representation of an entry SHOULD NOT be dropped between the GET and the PUT, and that servers MAY reject such PUTs if elements or attributes are missing.
" the syntax for editing Wikis not the syntax used for display."
The AtomAPI RFC needs to have this stated somewhere, in bold, near the beginning of the spec, maybe in a blink tag.
The XML::Twig Page Meatball Wiki: RdfForWikis raelity bytes :: /oreilly/books/hacks/spidering_hacks.html Russell Beattie Notebook - More Weblogs in the Real World: Spending My Weblog Karma Voidstar - Marc Canter notices SEA TWiki . Codev ....
"This means that there needs to be separate mechanisms for retrieving either the original source vs the formatted source. This can be achieved as simply as having different URLs for each function."
In our AtomWiki prototype, we store both versions by using <content type="multipart/alternative"> with 2 childs : <content type="application/xhtml+xml"> and <content type="text/x.wiki">
I generally agree with Joe re. letting the server handle page creation, and Moin's approach to datestamping does seem rather a hack.
The server-interpretation of links could be problematic though. I'm not sure about it being necessary to retrieve/send the WikiText version of the content - it is after all primarily just a way for humans to enter simple markup in a HTML form.
If the client was WSYIWYG, XHTML content could be shipped around and Wiki syntax wouldn't be needed. Links are a special case, but as there are plenty of extensions beyond WikiLinks already, this problem would have to be solved one way or another anyway.
Joe, I think you are confusing how you use the wiki with how it works. Yes, you can create a link to a non-existant page before it exists. But there is no requirement that a page has a have a link to it before it can be created. Nor is there a requirement that a non-existent page be fetched before created. Simply put, wikis are not stateful in that way.
Nor is there a requirement for camelCase. Try lowercasing the 'g' in any of those links.
As to versioning, the names and formats of the attributes vary (wpEdittime, nextver, version_mark, revision, editversion, datestamp, ...), but the approach is common to all wikis that I have seen, and is an alternative to explicit locking, and IMHO bears special mention.
Finally, I still see the requirement to upload a picture and name the URL at which it resides. Does Bulu handle images? How are URLs assigned in general with Bulu? Do you use the link tag within the content? That could work...
Joe Gregorio points to the mounting support for Atom in Wikis, and wonders if it's time to organize some interop testing. Sam points out some implementation issues. See also : AtomForWikis (on the Atom Wiki)......
Re. datestamps, note that ETag/If-Match can be used with PUT.
If-Modified-Since technically can also be used, but it has a one-second race condition not unlike the one we saw so effectively in the first couple months of the Atom wiki.
Sam,
"I think you are confusing how you use the wiki with how it works."
Probably true. What are the benefits you see of going outside the current interaction model?
"IMHO bears special mention"
Agreed, do you think the verbiage I used in my first comment covers that case well enough?
"Does Bulu handle images? How are URLs assigned in general with Bulu?"
Bulu doesn't handle images now with the RESTLog API, but the next version I am working on uses the AtomAPI and will handle images. It will use the same algorithm as I describe below for Entry URIs.
URIs assignment in Bulu: The URI is created from the title of the entry the first time it is created. The title has all non-alphanumeric characters turned into underscores and the resulting string is used as the file name. If a file exists with that name, a trailing index number is appended/incremented as necessary until no collisions are found. For example: If I post three articles in a row, all with the title "Link Dumps", then the three URIS will end with the names: Link_Dumps, Link_Dumps_1, Link_Dumps_2. Note that editing the title will not change the URI, it is only assigned once during the creation of the entry.
See Detecting the Lost Update Problem. I would try to use version numbers as etags as Ken MacLeod mentioned. This seems a good way of using the existing HTTP spec.
Hey guys- I just want to speak up in hopes that maybe my software might be able to use this api if it can.
I wrote a program called VoodooPad ( http://flyingmeat.com/voodoopad.html ) which is basically a desktop version of a wiki. I've also been working on an api to update web based wikis with xmlrpc (aka vpwiki api).
Anway, when I save the data I send it back in an xmlrpc Dictionary, which contains little bits about the page, including a plain text version of the page, along with and rtfd version of it- which is the native text format for VoodooPad.
What I was wondering was- if you do come up with an wiki version of the atom api, could you leave room for custom client information, so applications like VoodooPad could play nicely with it and still retain it's custom data?
Re. datestamps, note that ETag/If-Match can be used with PUT.
Unfortunately, I have yet to find a single Wiki that supports ETags. I'm torn. My feeling at the moment is that Atom should be defined in a way that enables and perhaps even encourages the use of ETags for this purpose, but does not require such. Alternatives such as If-Modified-Since and "hidden" elements should also be supported.
Probably true. What are the benefits you see of going outside the current interaction model?
The words interaction model sets of alarm bells in my head. Those words, particularly in conjunction with the notion of implicit state and coordination are sure to invite a series of flames from those of the REST persuasion.
One could perhaps wave these concerns off as "merely theoretical", but they have pragmatic implications. In particular, they impose greater requirements on the clients to have more knowledge of the target application. In this case, they can require a generalized web editing application to be aware that the target is a wiki, and therefore a different series of steps are required to create a page than for a weblog.
"IMHO bears special mention"
Agreed, do you think the verbiage I used in my first comment covers that case well enough?
I'm concerned specifically about the modified element. My concern isn't that clients will remove this element, it is that clients will "helpfully" chose to update it. I see one of two possible paths to take on this one: either declare that modified is always set by the server and state that PUT requests MUST NOT contain this element, or state that clients MUST repeat the original value of the modified element on PUT requests that act as a replacement.
URIs assignment in Bulu: The URI is created from the title of the entry the first time it is created.
So, I presume that you changed the title on No fishing entry? Would you recommend that a create - retrieve - replace dance be the way to achieve the Cruft-free URLs?
Let me be clear: I don't have a problem with individual servers or applications imposing policies on URLs. But such choices should not be imposed on everyone. If a server permits clients a limited ability to define URLs, such a capability should be able to be determined via introspection and implemented uniformly.
August: Atom certainly will allow custom client data, placed into custom namespaces, to be placed into the serialization format. We are discussing here adding some non-normative text indicating that clients and servers should retain and echo back such information, something that definitely sounds like a good idea.
Unfortunately, I can't think of a way to make this an enforceable requirement as far as the spec goes. But I can imagine writing up some compliance tests that encourage this behavior. Of course, failure would be merely a warning, but this typically is enough to get people thinking about such issues.
Sam,
I meant interaction model as in how users currently use wikis.
My comments were trying to point out that editing wiki pages can be done with the AtomAPI as is, without the need for new "policies and capabilities". Your link examples show that in one way wikis are slightly different from a weblog in that the 'createEntry' facet is never needed, in essence the entire URI space for the wiki is completely filled in, albeit with default template pages. This means that you only need the GET/PUT/DELETE actions on the 'entryURI'.
How would you suggest the Introspection file be modified to enable the "create by PUT" that you seem to be advocating?
"My concern isn't that clients will remove this element, it is that clients will "helpfully" chose to update it. "
Yup, that would be a problem. Either of your proposed solutions would fix that.
"So, I presume that you changed the title on No fishing entry? Would you recommend that a create - retrieve - replace dance be the way to achieve the Cruft-free URLs?"
Yes, I did change the title to get a nice cruft free URI. In this case I am using an implementation detail of Bulu to get the effect. I don't think any such policy should be part of the AtomAPI, as each server is in control of its own URI space and there shouldn't be any 'input' from the AtomAPI on how it allocates URIs.
"If a server permits clients a limited ability to define URLs, such a capability should be able to be determined via introspection and implemented uniformly."
Agreed, though I believe this is one of those things best left for later. I would suggest we wait and see what gets implemented and come back later and formalize the most popular systems.
Early in September Joe Gregorio blogged his thoughts on an extremely intriguing idea - an Atom interface to a wiki. Strangely enough it was a possibility I was considering at the time too. I did a cursory investigation on the source of Usemod (my...
Alors que nous commencions à développer notre Wiki Engine avec Benoît, j’avais crée cette page sur l’Atom Wiki compilant en mauvais anglais les réflexions que je me faisais sur les modifications à apporter à Atom pour l’utiliser dans l......
[more]
I think we should go with the Strong ETags / If-Match approach.
If an Atom client is going to make an Atom request to a wiki, either the request will have to go through a gateway like WikiGateway, or the wiki is going to have to add Atom support as a feature.
So it doesn't matter that wikis don't do ETags.
Different wiki clients want to use version numbers or modified dates or both, but the Atom protocol can use ETags or whatever the "best practices" HTTP field is for this sort of thing. WikiGateway can translate, or the wiki servers can learn to use the different field when they add Atom support. The process that wikis are trying to use the modification date and version numbers for maps onto ETags, so I think they will be sufficient.
What concerns me most about ETags is that it depends on the correct operation of clients in order for the server to maintain a coherent version history. That would invite mischief. So the only way I think that going with an ETag based approach make sense is if they are REQUIRED on PUT requests.
BTW, I don't buy the argument that because there must be a gateway or explicit Atom support that "it doesn't matter if wikis don't do ETags". That reasoning can be used to justify almost any feature.
What I would most like to see is an API which is as common as possible to as wide of a set of use cases as possible - first and foremost being weblogs. For single user weblogs, the requirements for coherency is versioning are quite different.
BTW, I don't buy the argument that because there must be a
gateway or explicit Atom support that "it doesn't matter if
wikis don't do ETags". That reasoning can be used to justify
almost any feature.
That's true, it could. But, right now there are a number of wikis, most of which basically use some sort of "Unreserved Checkout" scheme, to use the W3C article's terminology, and each of which has a slightly different way of doing it. As you pointed out,
As to versioning, the names and formats of the attributes vary (wpEdittime, nextver, version_mark, revision, editversion, datestamp, ...), but the approach is common to all wikis that I have seen, and is an alternative to explicit locking, and IMHO bears special mention.
Your "modified" proposal means coercing all of these different fields into the "modified" field. This doesn't seem different from coercing them into an "ETags" field or anything else.
And, the semantics of fields like "modified" could get confusing; as you pointed out, it may surprise developers to find that they aren't supposed to update a field named something like "modified" when they modify content. "ETags" won't be surprising this way.
So, basically, if you are going to choose a single field and say "this is the field that wikis should use to deal with Edit Conflicts", you can make than an "Etag" HTTP field as easily as a "modified" XML field. Either way you must depend on the client treating that field correctly. But the implied semantics of a "modified" field may encourage people to use it for something else than detecting edit conflicts. In contrast, I had never heard of an Etag before today (so I probably wouldn't abuse one), but upon reading that link, it's semantics seem to match exactly what wikis are using the datestamp, etc fields for; a unique identifier which distinguishes different revisions of the same resource.
May I have your permission to repost your comments on this page
1) On MeatballWiki, and
2) On AtomWiki, and
3) On InterWikiSoftware?
I'd like to get some feedback on these questions from the more knowledgeable folks at MeatballWiki, and I feel that InterWikiSoftware is the "canonical place" where people will be looking for such disussions. And, I'd like to have it on InterWikiSoftware for future reference.
Anyone else who sees this comment, I'd like to repost your comments, too, if you'd like to give me permission.
This is fairly obvious, but needs to be spelled out: the syntax for editing Wikis not the syntax used for display. This means that there needs to be separate mechanisms for retrieving either the original source vs the formatted source. This can be achieved as simply as having different URLs for each function.
Sounds good to me. I agree that the spec needs to mention somewhere that such-and-such a URL is for the "source", when such a distinction exists.
The Wiki edit model more closely corresponds to using HTTP PUT for creating new pages. In other words, the client determines the URL. Some webloginging systems support this, though more commonly the server determines the URL. However, I do expect that having the client specifying the URL will become more common with photoblogs and other mechanisms involving images. I suspect that some additional information should be added to the introspection file so that clients can determine server policies and capabilities in this reguard.
I agree. I don't think there is a need to ask the client to attempt a GET on a new wiki page before PUTing it, just because that is what users do today.
By the way, the Atom wiki mentions it already so maybe I don't need to, but ModWiki is an informal spec that specifies meta-data to go with wiki Changes. It might be good to recommend it in the Atom spec as the place to see how to represent wiki Change meta-data:
Bayle - if you find any my ramblings on this weblog entry worthwhile, feel free to repost them elsewhere. I'd only suggest a bit of crosslinking (both directions) so that people who care to do so can follow the conversation and/or see the original context.
I have a strong concern that Atom may be becoming too focused on the specific interaction between Atom clients and servers, setting a context that is beginning to exclude, if not already past excluding, tools that "work with the web". In the...
Early in September Joe Gregorio blogged his thoughts on an extremely intriguing idea - an Atom interface to a wiki. Strangely enough it was a possibility I was considering at the time too. I did a cursory investigation on the source of Usemod (my...
C’est un projet dont le but est d’écrire l’engin Wiki de nos rêves “from scratch”, quelque chose de résolument moderne. L’esprit originel était de développer en s’imprégnant des pratiques XPs, de se focaliser sur la simplicité, la propreté, le...
Improving TopicExchange Right now submitting a post to a channel requires people to either fill in a form on the channel page of their choice or send a TrackBack ping to the channel. Both are simple, but still harder than they should. How about...
Seb Paquet started a Wiki for playlists. These playlists are editable in the Wiki social style, which Webjay doesn't support.
Posting songs to Wiki playlists can be a chore, so I asked whether Webjay could do the posting of songs to the Wiki playlist. After a bit of back and forth the idea of Atom came up.
The abstraction here is that we have a microcontent format (a playlist) hosted on a Wiki, and an application (Webjay) to support that microcontent format. We'd like to end up with each component doing what it is best at, so the microcontent app would handle application specifics and the wiki would handle the things that its good at, like changelogs.
Yahoo My Web Relaunches Tonight Yahoo has two social bookmarking services? categoriz huge list of web 2.0 companies The Intention Economy | Linux Journal moving from attention to intention The Attention Economy: The Natural Economy of the Net some...