Re: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

>>> 1. Must the resources pointed to by the SOURCE header be
>>> WebDAV-compatible?
>>
>> a) What is the definition of a "WebDAV-compatible" resource? Being the
>> member of a WebDAV collection?
>>
>> b) I'm tempted to say: no.
>
> If an OPTIONS response for the resource includes the DAV: header with 
> level
> 1 or 2 support, it's a WebDAV resource.  If the answer is "no it's not a
> WebDAV resource", then how is authoring of the dynamic content possible?

That is not relevant.  The resources might just as easily be ftp or file 
URLs,
or might only be authorable by someone with authorization or coming from
a particular IP address.  Identifying the source does not imply 
authorability
on that resource, nor does it need to in order to be useful to the user.

>>> 2. Must the source property point to ALL the files involved in
>>> producing the result?  Be careful here -- there could be data files as
>> well as source
>>> code, libraries, build files, etc.
>>
>> I don't think that's feasible.
>
> If it's not possible to view and edit or replace all the files involved in
> producing the result, then how is it possible to authoring dynamic 
> content?

How is it possible to author an e-mail message when some of the message
header fields are generated?  That question is simply not relevant to
the issue of identifying the source of dynamic content when the server
does have a URI for that content.

>>> 4. Clearly in order to get the source code for a dynamic resource, the
>>> client must do a GET to the URL(s) in the source header. But what URL
>>> should the client send PUT to?  Does PROPFIND address the source
>>> code or the output?
>>
>> Source and dynamic resources are different resources with
>> separate URLs. All
>> HTTP/WebDAV methods operate on the respective request URLs.
>
> Compare with the next question/answer to see the inconsistency with this
> position.

They are different resources.  The effects of a particular method on any
particular resource are defined by that resource.  The source for one
resource may itself be a dynamic content resource with its own source URI.

>>> 5. What does it mean when a dynamically-generated resource is the 
>>> source for
>>> a COPY request?  Is it different when it's the source for a MOVE 
>>> request?

If that isn't already defined by RFC 2518, then it isn't defined for any
resource.  There is no distinction on the Web between dynamic and static
content.

>>
>> I think that's open to discussion. For COPY, it seems it
>> would make sense to
>> require that the newly created resource must behave as the original
>> resource, so it should still be a dynamic resource, and have
>> the same source
>> links. MOVE obviously MUST move the resource -- and if this
>> can't be done by
>> the server, the request must fail.
>
> All right, now we see the inconsistency.  Say we have a dynamic resource,
> "foo", and the server reports that there's only one source file,
> "foo-source".
>
> If all methods operate on the respective request URIs, that means that a
> COPY request to foo must operate on the dynamically-generated content, not
> the source.  So wouldn't that mean that a snapshot of foo is copied to the
> destination?  It wouldn't be a dynamic resource.  Fair enough. Presumably 
> we
> can COPY foo-source to get a second dynamic resource.  But what happens if
> you MOVE foo?  Does it operate only on a snapshot of the dynamic resource?
> What does that mean?

Why is this confusing?  If a resource does not allow COPY, then it would
not respond to COPY with 200.  There is no magic being done behind the
curtains.  What does COPY mean for RFC 2518?  It means the same thing for
both dynamic and generated resource -- there is no difference between the
two.  Some resources will simply not allow COPY or MOVE.  That is why it
is NECESSARY to point to the source of the resources, since those other
resources are the ones that usually can be copied or moved.

>>> 6. How does a client *create* dynamically-generated Web pages? Think of 
>>> all
>>> the problems with that - where should the client upload new source 
>>> files?
>>> How can the client specify what URL in the main repository is actually 
>>> an
>>> invocation to handle this dynamic resource?
>>
>> Right now I'd say that's server-specifc. Depending on how dynamic 
>> resources
>> are implemented, it's hard to see how there can be a generic way to 
>> author
>> them.

There are many ways in which a namespace can be constructed on a server.
The user creating a service generally knows what they are doing or are
following the instructions provided to them by the server owner.

>>> 7. How does a client add a new source file to an existing set of source
>>> files?  E.g. assume I want to modify a JSP to call a new object in a new
>>> library.  That library is not on the server yet.  How do I upload
>>> it?  Where
>>
>> Again, I think this is server-specific. The server may allow you to PUT 
>> the
>> file anywhere, or at a specific location. And of course a server may 
>> allow
>> PROPPATCH on the source-set property.
>
> Seems to me both 6 and 7 are essential features.  I don't understand how
> authoring dynamic content is supposed to work unless we offer them.

The degree to which the server's implementation space is itself a WebDAV-
enabled name space is dependent on the particular site configuration and
none of our business.  If they are authorable, the user will be able to
author them.  There is no need, nor any desire, for such security-sensitive
activities to be automatically handled by authoring tools.

>>> to? How do I indicate to the server that it's a source file and not a
>>> content file?
>>
>> What's the difference?
>
> A new source file is a new file which will be interpreted or compiled by 
> the
> server in order to produce dynamic content.  By "content file" I meant
> static Web page, or regular resource.  How can the client create a new
> source file and let the server know it's supposed to interpret or compile
> it?

The server will either already know how to interpret its name space or
the client will author (via another URL) the appropriate configuration
or binding needed to enable the dynamic resource.

....Roy

Received on Wednesday, 12 June 2002 16:04:24 UTC