Re: [Nautilus-list] Nautilus now officially dependent on Ammonite when compiled with --enable-eazel-services

[Greg Stein <gstein lyra org>]

On Thu, Aug 31, 2000 at 02:48:48AM -0700, Maciej Stachowiak wrote:
> Greg Stein <gstein lyra org> writes:
>...
> > > So I think we would need to see some major concrete benefits to
> > > using Neon instead of implementing missing functionality directly in
> > > order to switch.
> > 
> > Concrete benefits? Sure. Areas where gnome-vfs (http/dav) is lacking:
> 
> I'll comment first that I don't know what many of the below things
> are, so I don't know how they benefit the user.

No problem. We'll wait for Ian.

> > *) Digest authentication
> > *) HTTP/1.1 support: chunked transfer encoding, persistent connections
> >  [ note the above two are *required* by RFC 2518 (WebDAV) ]
> 
> Required of the client or required of the server? If the former, we
> are in trouble.

Both.

Inside secret: it is an RFC requirement -- there is nothing inherent in DAV
that requires either. Requiring digest promotes better security; requiring
HTTP/1.1 promotes better infrastructure.

[ for example: mod_dav does not enforce either of these. however, an admin
  is completely justified to enable/enforce them in their server config ]

> > *) SSL support
> 
> We're waiting on the legal issues (RSA patent deathwatch)

Oh. Right! We're just a few weeks away. :-)

> > *) proxy support
> > *) proxy authentication
> > *) 100-Continue handling
> > *) bugs due to lack of broad use and young codebase.
> >    [ for example, the PROPFIND result parser does not distinguish between
> >      the DAV:getcontenttype and http://example.com/davprops/getcontenttype
> >      elements. it also does not handle the DAV:status element. ]
> > *) 301/302 redirect handling
> > *) extended property (metadata) support: PROPFIND, PROPPATCH
> > *) DAV lock handling
> > *) choice of libxml or Expat   [GNOME would just use libxml]
> 
> It seems at least some of these things could not be cleanly expressed
> in the gnome-vfs API.

Much of it would not necessarily be exposed. I'm not sure if the VFS API
exposes metadata as a first-class concept on files/dirs. The rest is
probably internal improvements for efficiency, interoperability, and better
response to varying server configurations.

> And I think we do have proxy support, at least I remember Mike Fleming
> angsting about a proxy-related checkin.

gnome-http has it. gnome-vfs/modules/http_method.[ch] does not appear to
have any proxy support. Possibly other vfs modules have proxy support (for
example, maybe the FTP module).

> > I am not intending to knock all the great work that has gone into it. But
> > there is so much more that is possible. And with little development work for
> > you, too :-)
> 
> I would love it if Ian McKeller, who's done most of our WebDAV and
> http stuff, would comment on this stuff. I don't really know much
> about it. I'm just semi-rationally afraid of adding mroe dependencies.

Again: I understand. More dependencies is always a bit nerve wracking :-)
Maybe I'll just trundle over to the Eazel office and beat you into
submission... ;-)

I am interested in Ian's thoughts. Last time we traded emails, the async was
the big blocker (which appears to have been solved). I forget what some of
the other issues were.

[ hmm... I think I even got an email from Ian recently... gotta go check my
  mailbox ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/