Re: [FYI] New batch of CVS commits

Hi  Everybody! :)

Thanks Jose for the announce!  :)

As I promised, I'm sending to you all more informations about the new 
functions in the libwww: the WebDAV module and the Extension Methods. 
 The first one is the new module HTDAV. This module has  high level 
functions for all WebDAV methods (that is, all methods described in 
RFC2518). I made this module very similar to HTAccess. So, in the same 
way that we can do a GET/PUT using an absolute URL, or a relative URL, 
or either using an HTAnchor , we can, for example, lock a resource 
identified by an absolute URL (using the function HTLOCKAbsolute) , or 
by a relative one (HTLOCKRelative), etc., with HTDAV module. The second 
modification is the extension methods Those methods are undefined 
methods that can be set by the application dynamically. So, an 
application that wants to use some new methods from Delta-V 
specification, for example, will be able to set an extension method to 
the desired method and use the libwww to do the request (even if the 
libww knowns nothing about Delta-V)...


The HTDAV module define high level functions for all methods in RFC2518. 
 This module also defines a new structure: HTDAVHeaders. This structure 
encapulates the WebDAV headers that may/must be used in WebDAV requests. 
The client should create an object HTDAVHeaders (as the rest of libwww 
objects, there are functions to create _ new _ and to destroy _ delete _ 
these objects), and  set the desired headers (If, Depth, Destination, 
LockToken,etc), using for this the setting functions also defined in 
HTDAV module (for example, HTDAV_setIfHeader, HTDAV_setDepthHeader, 
etc). An object HTDAVHeaders is always passed as parameter in the HTDAV 
function. So, I could test if the necessary headers are presents before 
send the resquest to server. If the request is not ok (for example, a 
COPY request without Destination header, or a UNLOCK without 
Lock-Token), I don't send it, and the application doesn't lose time or 
network resources unnecessarly... Besides this, many of those functions 
in HTDAV module receive also a parameter "xmlbody", a XML body to be 
used in the request. This body is sent using "Expect: 100-continue" 
header. Jose and me discussed a lot about the use of this header in 
WebDAV request, since RFC2518 says nothing about that. After many 
arguments, I decided to listen to him and to use this header for all 
WebDAV requests that may contain a body. :-)

So, using this new module, an application may do WebDAV requests with 
only a few lines of code... :-) For example, we can do I MKCOL request 
using these lines:

HTAnchor dst = HTAnchor_findAddress(full_address);
HTRequest * request = HTRequest_new();
HTDAVHeaders * headers = HTDAVHeaders_new();  
HTMKCOLAnchor(request,dst,headers);


These functions in HTDAV module are supported by some others changes in 
libwww. I try to not change many things in libww, but some changes had 
to be done... In brief, I've changed the HTError and HTUtils modules to 
define the new WebDAV status codes and the equivalents error codes. I 
also changed the HTTP module to accept those status codes,  specially, 
207 Multi-Status, that have been used in libwww for other purposes that 
not the WebDAV definition, as Steinar Bang, Xinju Wang and others 
discussed here (see october to december/2001 mail list archive). I used 
the code suggested in that discussion the solve the problem, and it 
works fine.. :-) Only 102Processing status code is not working... :( If 
someone has any suggestion, it is wellcome!


Now about the extension methods. Those methods are 7 undefined methods 
in HTMethod structure. They have no name, and "a priori" they work as 
invalid methods. Only when an application assign a name for those 
methods, they became valid methods. The applications may do it by using 
a new function in HTMethod module, HTMethod_setExtensionMethod. By this 
function, the application gives a name to the extension method and also 
tells to the libwww if that extension method will use an entity to send 
a message body (and, by consequence, use the "Expect: 100-continue" 
header).  If the application does not want to use this header (for 
example, an application that must deal with a broken HTTP server, or a 
method that never send a message body), it may register the extension 
method without this option of "Expect 100". For the cases were the 
application wants to use an extention method with a message body, but 
without "Expect 100" header, I added in the HTRequest a new 
"messageBody" field. This filed  cames from a suggestion from Josh Watts 
and others, posted in this list in July. It is a "char *" field that is 
only send with the request if it is defined. So, the application may 
chose how to send the message body according to its needs. Consequently, 
through these extension methods, we may use the libwww to build 
applications that use or test new specifications or protocols, and even 
applications to deal with broken servers...

Of course, there are some limitations: I defined only 7 extension 
methods. If the community feel that is not enough, we may increase it to 
15 (then we'll have exactly 32 methods, each one identified by a bit). 
More than 15, I think that will not be necessary (if you need more than 
15 new methods, problably it will be much more easy build a new module 
for this, as I do with WebDAV), but onmy the future may decide it...  :-)

These modifications have been tested using testing applications (some of 
them are now examples in libwww cvs base) under a Linux system. I didn't 
have time to test it under windows system, neither in other "unix-like" 
systems (like Solaris or BSD). I don't think that will be a problem 
under these systems, but comments are wellcome (windows users, please, 
try it!! :-))... As others libwww modules, the HTDAV module has its 
documention in HTDAV.html, and all modifications that I made in libwww, 
including the extension methods, have been describe in the correponding 
HTML documentation (for example, changes in HTMethod are described in 
HTMethod.html).

Ah! As Jose said, these modifications are not enabled by default. To 
enable them, we must use the configure options "--with-dav", for WebDAV 
module, and "--with-extension",  for the extension methods.

Well, as everybody can see, I used many suggestion from the list and 
from Jose Kahan. Thanks everybody!!  :-). This commit is product of the 
libwww community. WE made it. We discussed in the list, I used the 
suggestions in my job, and now everything is available for everybody in 
libwww cvs base... I think we should do more this: contribute! If 
somebody is building something (or fixing a bug) that may be useful for 
others, s/he should think in add it to the libwww cvs base. It is not so 
difficult, anybody can do this... :-)) This month we have me and Vic as 
new contributors.. A new month is coming, who will be the next? ;-))


Best regards!! (and sorry about the looooonnnng mail ;))

Manuele



Jose Kahan wrote:

>Ah, I guess you didn't expect to see this message again :)
>
>I commited the patch for the reentrant gethostname functions in HTDNS.c
>(sorry, I have misfiled the reference to this patch, so I can't quote
>it right now).
>
>And that was not all!!
>
>I cvs tagged the whole libwww CVS space with a "before_dav" tag and
>then...
>
>Manuele commited all her webdav and HTTP extension modications to cvs :) Many
>thanks to Manuele for her contribution. She'll mail to the list more 
>information concerning her patches and how to use the new DAV methods soon 
>(hopefully tomorrow). You need to use a configure option to invoke them. Try
>configure --help to see what are the name of the options.
>
>If you find some bugs after this patch, please report them directly to
>this mailing list.
>
>The libwww/Changelog file contains all the details.
>
>Have fun!
>
>-jose
>
>
>

Received on Friday, 22 March 2002 11:06:13 UTC