RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED

Lisa,

thanks for compiling this list of issues. I agree that we need to think
about them, but I'm not sure that we have to *solve* them all. Sometimes a
problem just is too complex to be solved completely in the first (or
actually, second) attempt, and it makes sense to concentrate on the subset
of issues that's simpler and well understood...

> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Sunday, June 09, 2002 2:20 AM
> To: 'Webdav WG (E-mail)'
> Cc: 'Julian Reschke'; 'Joe Orton'
> Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED
>
>
> I've been thinking more about the source property problem.  It's
> deeper than
> it looks.  Here are *some* of the problems, the things that are not
> specified.  More are sure to be found as we start answering the initial
> questions:
>
> 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.

> 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.

> 3. When the source property points to multiple files, what role
> does each of
> them play?

The one defined in the role attribute (if present).

> 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.

See <http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm>,
section 6.2.3.

> 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?

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.

> 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.

> 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.

> to? How do I indicate to the server that it's a source file and not a
> content file?

What's the difference?

> 8. How do I configure the server's classpath?  How do I get it to compile?

Out of scope.

I agree that it would be interesting to see how the source-set property can
be applied to a Servlet engine, and to come up with interoperable ways to
author servlets...

> I don't think that Julian's proposal goes very far towards a complete
> solution.  As it stands, it addresses only part of #3, in that it
> provides a
> syntax for describing roles, though it does not specify what the
> roles are,
> which is clearly necessary for interoperable implementations. Moreover, it

Well. Please then enumerate all roles we'll need for interoperability. If
you think RFC2518+ needs to do this, we are free to assign names, qnames or
URIs to these roles and we are done. I personally don't think we should get
into that business (at least not now).

> creates a significant new dependency on XLink, a non-trivial
> specification.

I agree that XLink itself is non-trivial. But we depend only on a very small
subset of XLink (simple links), and not using this subset makes our own work
harder, not simpler (because we would have to duplicate the work done in
this recommendation).

For those who haven't looked at XLink, here's what we depend on:

- a well-defined namespace
- two attributes (role and href)

> In view of the problems that remain to be solved I don't think
> that XLink is
> bringing enough to the party to justify the additional complexity.

Could you please explain where you see *additional* complexity? Usually,
reusing existing methodology *simplifies* a specification.

Using the same line of argument one could say that using XML causes
additional complexity, and therefore WebDAV should have used a simpler
marshalling format.

> That said, instead of getting bogged down in syntax, I'd like to see us
> figure out what the abstract semantics of a new solution would be (see
> questions 1-8 above). Once we've got that stuff nailed down we can worry
> about how to encode it on the wire. In view of the complexity we already
> know about, I suspect this is going to turn out to be a
> significant project.

It depends on what we want.

a) Just fix the source property defined RFC2518 for inclusion in RFC2518bis?
That was my understanding.

b) Completely solve the problem of remote authoring? That's hard.


Julian

Received on Sunday, 9 June 2002 10:43:13 UTC