RE: Is KEEPALIVE worth keeping?

We originally envisioned that there would be servers with multiple sets of
live properties active in different parts of its namespace, in which case it
was unclear how to handle the semantics of a COPY from one live property
space to another. Keepalive was designed to make these copies more
predictable from the client side.

But, these kinds of servers aren't prevalent, and it's not clear that
clients really want these semantics anyway. The lack of adoption speaks
volumes.

I'm in favor of dumping it -- a later extension could add it back in, if
desired.

- Jim


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Monday, February 04, 2002 12:33 PM
> To: Lisa Dusseault
> Cc: Julian Reschke; Stefan Eissing; w3c-dist-auth@w3.org
> Subject: Is KEEPALIVE worth keeping?
>
>
>
> As per the note below.... again... if anyone has an interest in keeping
> KEEPALIVE alive, please speak up.   I'll mark it for deletion next weekend
> if noone speaks up.
>
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
>
>
>
>
>
>                       "Lisa Dusseault"
>
>                       <lisa@xythos.com>        To:       "Stefan
> Eissing" <stefan.eissing@greenbytes.de>, Jason
>
> Crawford/Watson/IBM@IBMUS, "Julian Reschke" <julian.reschke@gmx.de>
>                       01/31/2002 01:05         cc:
> <w3c-dist-auth@w3.org>
>                       PM                       Subject:  RE:
> Issue: IS_HREF_A_CHILD_OF_KEEPALIVE
>
>
>
>
>
>
>
>
>
> There is a much deeper issue with keepalive, and that is that no client at
> the interop claimed to use the  feature.  Therefore interoperability has
> not
> been, and cannot easily be, demonstrated.
>
> Are there now clients out there that can demonstrate that keepalive works?
> Or is it one of those ideas that just isn't useful enough to clients for
> them to implement?
>
> If its not useful enough for clients to implement, then it should be
> removed
> from WebDAV so the protocol can go to the next phase of standardization.
>
> Lisa
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> > Sent: Thursday, January 31, 2002 7:50 AM
> > To: Jason Crawford; Julian Reschke
> > Cc: w3c-dist-auth@w3.org
> > Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE
> >
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> > > [...]
> > > Julian alluded to the possibility of keepalive going away.
> FWIW... I
> > > don't see anything like that listed on the issues list.
> >
> > The issue is not explicitly on the list, however it is related
> > to COPY_LIVE_PROPS.
> > The issues I have with keepAlive are
> > a) how does the client know which property is live in the first place?
> > b) deltaV copy semantics forbid using keepAlive on version properties
> > c) If the destination is on another server, WebDAV has no means to
> >    fulfill keepAlive. It is not possible to know if the remote server
> >    knows the requested live props.
> > d) Is there any server/client using it? (I have not seen any)
> >
> > I would propose to
> > 1) remove keepalive, maybe allow omit
> > 2) change default copy behaviour to _not_ copy live properties
> >
> > //Stefan
> >
> > > J.
> > >
> > > ------------------------------ Julian wrote... --------------------
> > > Hi.
> > >
> > > Currently, RFC2518 says in 12.12.1 [1]:
> > >
> > >    <!ELEMENT keepalive (#PCDATA | href+) >
> > >
> > > So individual properties are identified by "href" (which doesn't
> > > make sense
> > > in the general case).
> > >
> > > So (assuming that propertybehaviour/keepalive isn't dropped
> > anyway), this
> > > will need to be changed to:
> > >
> > >    <!ELEMENT keepalive (#PCDATA | prop+) >
> > >
> > > where DAV:prop contains property elements.
> > >
> > > Julian
> > >
> > >
> > > [1]
> <http://www.greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_keepalive>
> >
> >
> > ------------------------------------------
> > Phone: 914-784-7569,   ccjason@us.ibm.com
> >
> >
> >
> >
>
>
>
>

Received on Monday, 4 February 2002 18:18:15 UTC