One other note: The plan up until last week had been to integrate Demokritos as the APP solution. However, as I came to discover, on a Windows box, there are only SVN bindings for Python 2.3. Demokritos requires Python 2.4, which, as I came to discover, was the reason I couldn't get anything to work as on my Windows dev-box as expected. So, for now at least, I chose to roll my own until such time as Python 2.4 bindings for SVN become available, or I become a MUCH better Python programmer, and simply fix the problems between the version differences myself.
Its easier to move forward with the languages I understand best that attempt the second mentioned solution, so for now this is the route I have chosen. On 6/7/06, M. David Peterson <[EMAIL PROTECTED]> wrote:
Hi folks, So I have basic support for APP built into the AtomicXML/AtomicRSS code base [1], and had planned today to spend my time working with the latest spec, line by line, to begin to finishing out full support. Thats when I ran into something I new was a hot topic of discussion from years past. I can only assume that this, # POST is used to create a new, dynamically-named resource. # PUT is used to update a known resource. differs from the explained difference in RFC2616 [2] for good, solid, and fundamental reasons, so I am not attempting to start any sort of late-breaking war here, and simply asking if someone can point me to the best possible URI in which explains the reasonings behind the use of POST and PUT opposite that which is stated in RFC2616. I would REALLY like to finish out this support ASAP, so gaining clarification via a simple "Please see [URI]" is all I need (I hope, anyway) such that I can make sure I handle things the way they are supposed to be handled as per the APP spec. The one area that has me thinking "I guess this could be why..." is the fact that not all major web browsers support PUT, while the same browsers all support POST, so using this as a basis, from a web browser that only supports POST one could create a new entry, but would be unable to edit an existing entry, where as using standard HTTP 1.1 definitions they would not be able to create an entry, and instead only edit an existing entry. Definitely a chicken/egg problem with the latter, where as with the former, regardless of how it came into being, at least you have a definitive chicken as a result. Thanks in advance for your help with this! [1] - @ http://dev.extensibleforge.net/browser/trunk/Research/GlobalClip/src/x.Instance/Web.config?rev=298 check-in notes related to the Web.config file updated with the actions associated with the HTTP verbs as per RFC2616: In what should be fairly obvious, I am using file extensions to represent the action that is desired to take place upon the atom feed. for .omx extensions only GET and HEAD are allowed, for .atom only GET, for .update, only POST, .create, only PUT, and .delete, only DELETE. This adds a layer of "obvious" to the action that is taking place (or at very least is being requested to take place.) This will allow for a fairly simple and straightforward way to access, edit, update, and delete a particular atom feed, or entry contained within that feed. For example, http://extf.net/blog/2006/06/01/This_Is_An_Entry.create would create the entry in the folder 2006/06/01/This_Is_An_Entry, http://extf.net/blog/2006/06/01/This_Is_An_Entry.update would update that same entry, http://extf.net/blog/2006/06/01/This_Is_An_Entry.atom would return a copy of the atom feed for that entry, and http://extf.net/blog/2006/06/01/This_Is_An_Entry.delete would delete that entry. A simple GET or HEAD request to the folder would return the format that matches the device/browser sending the request. The nice part about using this system beyond the "obvious" layer is that we can then handle this with a simple ASP.NET handler. Whether or not the folder structure is set up on the file system itself, contained in a DB backend of some sort, etc.. is of no concern as the file extension is handled as specified in our Web.config file, so as we continue to develop our backend system we can implement as many "file-system" types as we might want (SQL Server/SQL Server Express, PostgreSQL, S3, LiveDrive?, GDrive, whatever+other+drive, POFS (Plain Old File System), etc... Doesn't matter to us on the frontend, and the backend can be chosen based on the personal choice of the implementor. Simple. [2] @ http://www.ietf.org/rfc/rfc2616.txt, page 54, section 9.6, third paragraph The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request. -- <M:D/> M. David Peterson http://www.xsltblog.com/
-- <M:D/> M. David Peterson http://www.xsltblog.com/
