[Zope3-dev] DISCUSS: Correct sequence for PUT

Paul Everitt paul@zope-europe.org
Thu, 20 Feb 2003 14:38:32 +0100


On Thursday, Feb 20, 2003, at 00:05 Europe/Paris, Jim Fulton wrote:

> Paul Everitt wrote:
>
> ...
>
>> 2) I'm not sure Zope 3 is doing the PUT correctly.  I did a PUT of a 
>> new resource, and RFC 2616 (HTTP/1.1) Section 9.6 says that a status 
>> code of 201 should be returned.  Also, the server should return a 
>> Location: header with the URI of the newly created resource.
>> Perhaps I'm reading 9.6 incorrectly?
>
> Maybe, but I probably just missed these points. This should be easy 
> enough to fix.

Thanks.  Note that it isn't currently a problem for me.

> Would you mind submitting a collector entry.

Done.

>> 3) Finally, I gentle plea for a feature.  In Moztop (and in the 
>> Rotterdam skin), I'd like to support Undo from the client, without 
>> visiting a page.  That is, I'd like the most recent transaction to be 
>> undo-able simply by performing a gesture (click on an Undo button, 
>> for instance).
>
> Well, we definately don't want that, as the most recent transaction 
> might not be what
> you think it is.

Right.  I meant, "most recent transaction sent from this moztop".

>> To avoid sending the user to a page and making them select a 
>> transaction to undo, I propose that Zope return transaction ids as 
>> part of the response.  This could be in an HTTP response header.  Or, 
>> for things like PUT, we could use the response body (which we're not 
>> using right now).
>
> This idea has merit. I'm not sure how to plumb it cleanly.

Ok.

>> Finally,
>
> That's your second finally.

oops.

> > I'd like some advice on how to handle the sequence for creating
>> richer objects.  Let's say I want to create a Smart Image without 
>> filling in an HTML form.  I want to create it using HTTP/DAV verbs.
>
> I don't think DAV is a very good fit for this, but ...

Perhaps.  I think that Tamino and Exchange are using DAV for these 
kinds of purposes, but perhaps they also are doing some hijacking.  
They have a different model, though.  Instead of calling remote 
functions with arguments, they are creating content that conforms to a 
schema understood by client and server.

For the purposes I need in Moztop, either way will work, procedural or 
known-schema.

Do you have another suggestion for how to do this?

>> To make this hard, presume two constraints:
>
> ...
>
>> 1) HEAD to see if it exists.
>> 2) PUT to create it, sending as the request body some XML for 
>> construction.  (I could do a PUT and then a PROPPATCH, but after the 
>> PUT it is alread constructed, so I defeat the constructor.)
>> 3) HEAD, just in case the server thinks the URI is different. :^)
>> 4) PUT to actually send the body.
>
> This should be possible. You'd define a named IFileFactory adapter
> with the suffix as the view name. This factory could parse the body to 
> get
> the initial parameters and create the object. The object would then
> have a IWriteFile adapter to handle putting thye body.

Ok, makes sense.

How could we distinguish from the existing PUT case that you have now, 
and the PUT case I am proposing?  (I have some suggestions, but I'm 
already in over my head, no pun intended.)

Do you know of any realistic (e.g. we've seen them before) cases where 
the URI returned should be different than the URI submitted?

--Paul