Re: [platform-webdav-dev] Suggestions

["Tim Ellison" <Tim_Ellison@xxxxxxxxxx>]

Hi Jason,

> I'm considering submitting two changes (and a few minor one's) to the
> org.eclipse.webdav tree.

Great!

> One is to make it easier for someone to tell the library how to
> authenticate them.  It's too difficult to do right now.    I just want
> to add a method to IContext.  Something like
>
> setBasicAuthorization( String userid, String pw )

The context is a data structure, so I'd be reluctant to add this type of
behaviour, see below.

> But I realize there's a slot for authenticator to do this sort of thing,
> but I'm not quite sure how to use it.   I'm guessing that one must do
> something like...
>
> remDavClient.getHttpClient().setAuthenticator( authenticator );
>
> Is that right?

Yes.  You have to create a http client to pass in to the constructor if the
remote DAV client, and that is the place where you define the
authentication for that transport.

> If so, where do we get an authenticator?

You get to write that bit yourself :-)

> I don't see any implementations.

There is an example, but the API is the interface.

>  Do we actually have to implmement one ourselves?
> If so, is that by design?  (It seems like except for the possibility of
> persistance, it's a pretty standard item.  And a method implementing it
> would clarify some of the semantics.)

Maybe the name is misleading, but the authenticator is the class that
provides the password for a given domain/realm, and it is up to the
application how that password is obtained.  I agree that there are certain
common scenarios that are not implemented, prompting the user (where you
have a UI), getting the info from an encrypted file, etc.  In the example,
there is a simple text prompt via the console and the info is cached ina
hashtable for the duration of the application.

> The other thing I'd like to do is provide a stream or string or some
> other way to specify the body of requests like PROPFIND.  Passing a DOM
> makes a lot of sense at the receiving server, but at the client the only
> advantage is that we can know that it's actually XML that's passed.  On
> the negative side, it is easier to read and spot bugs if the actual
> string form is listed in the code (not a bunch of operations to
> construct a DOM) and it's a lot faster (and smaller) to simply do a
> simple string manipulation to fill in a spot or two in a string template
> than to construct a DOM and then flatten it to send down the wire.

Well we can debate whether or not it is more or less error prone to
construct XML as text or a DOM, but beside that discussion, although the
DAVClient API is DOM-based the expected usage is via the ElementEditor
hierarchy.  That is, you create a new Document and then add to the document
using the appropriate element editor.  The editors have high-level methods
for manipulating webdav defined elements, and are designed for constructing
requests and decomposing responses.  Once the client has used the editor to
construct the document it is passed in the DAVClient API.  There are
generic methods to add elements beyond those defined in the specification,
so it is forward compatible and supports proprietary extensions.

I would not like the entire API to be String (XML text) based becuase I
think this high-level functionality is much more usable.  However, we can
look at providing a path to the socket so the body of a 'canned' request
can be written directly (I'm assuming that you do want the DAV/HTTP
characteristics of the socket or else you would use java sockets directly).

Regards,
Tim