"Okay, so it's kind of a push to imply that the Atom Publishing Protocol is "hard to understand", or "hard to implement" given the advanced toolsets for reading and writing XML we have in each of our modern day developers toolbags and the fact that the specification is well written, and EXTREMELY detailed in all the right places. But as I recently learned, a life times worth of assumptions in regards to things like what PUT and POST actually mean, when to use which one, and why, can easily lead you down the wrong road to completion of support for APP. This series of wiki entries is designed to document my own efforts of implementing full (and verified as such) support for APP such that others can gain a greater understanding of this process without the need to make any or all of the same mistakes along the way that I do (and mistakes will be made... Thats part of the software development process and is nothing to be ashamed of. Unless, of course, you claim that you haven't or don't make mistakes. Then there is something to be ashamed of because you are a lieing ;) :D.)
I'm a good portion into finishing out the first step in regards to implementing a simple API (.NET 2.0 + Saxon on .NET-based) for creating, editing, and deleting a new feed or entry-based Atom file, as well as editing or deleting a specific entry in an existing Atom file. Based on my experience from a couple days ago in regards to what PUT and POST actually mean compared to what I thought they meant, I've come up with the following list of rules,
A) If Elliotte Rusty Harold had troubles understanding the difference between PUT and POST, then there's not a soul on this planet who should feel bad if they have a hard time understanding it to.
B) No matter if you don't understand it, or even further if you disagree with the proper interpretation (hows that for manipulation of terms :), i's not okay to build support for APP incorrectly.
C) Wiki's are a good way to document processes at the community level. (not really a rule, and instead an observation)
D) Documenting the implementation process while the implementation process is taking play ( e.g. "Hmmm... that was a while ago... I can't remember why we chose to do it this way...") is ALWAYS the best way to ensure a long term understanding of any particular process and the reasoning used for using a certain method during this process.
E) C + D = A nice way for others to get involved, and to help fix mistakes along the way such that the final result is the of the best quality possible, and is easy to understand from the viewpoint of more than just one person.
Anyone and everyone is invited to join in on the fun. While I need to move the code base from one directory into another, the location of the repository in which contains (or will contain shortly) the code base I am working from is,
svn://src.extensibleforge.net/trunk/Extf.Net
This code is web-browser viewable @ http://dev.extensibleforge.net/browser/trunk/Extf.Net where you will also find a Trac interface in which you can create and/or edit tickets for feature requests, bugs, etc... This will be the interface used for the project management side of this project. The wiki located @ http://understandingatom.com will be the documentation side.
PLEASE NOTE: Probably the best help I could possibly hope for would be that of advisory styled "uh, you need to do this like this for it to be correct" or "a faster and/or cleaner and/or better way to build this function would be...". I'm not worried about being wrong in regards to my interpretation or my choice for implementation, and instead want to build a solid library for the .NET platform in which anyone can freely and openly use as they might wish (all code is being licensed under a Creative Commons Attribution-ShareAlike license unless anyone were to suggest and quantify a reason as to why another OSS license would better serve the interest of ensuring the least amount of limitations can be set into place for the greatest benefit to the community as a whole.)
Thanks in advance to anyone and everyone who chooses to get involved with this in one form or another!
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
