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

[Greg Stein <gstein lyra org>]

On Wed, Aug 30, 2000 at 09:38:45PM -0700, Maciej Stachowiak wrote:
> Greg Stein <gstein lyra org> writes:
> > On Wed, Aug 30, 2000 at 02:22:25PM -0700, Mike Fleming wrote:
> > 
> > Yah, I know, and I consider it a most unfortunate occurrence. I've posted
> > here before regarding Neon and the gnome-vfs stuff. The HTTP and DAV code in
> > gnome-vfs is at least a year behind Neon (auth, proxy, SSL, better DAV
> > support, etc).
> > 
> > In those previous conversations, the answer was always "but gnome-vfs is
> > async, so we can't use Neon". Bleh. That is what threads are for (and GNOME
> > is already defined to be threaded, so this isn't a Bad Thing(tm) to depend
> > upon).
> 
> Actually, most GNOME apps try to avoid using threads and build
> everything out of an async model. The fact that Gtk+ calls can only be
> made safely from one thread at a time makes this a fairly sensible
> choice.

*nod*

> The async thing is not quite correct. gnome-vfs actually uses threads
> and synchronous internally but presents this to the app through an
> async interface. So the async thing should not be a blocker.

Ah. This is good news. I'm glad that Neon could actually fit into the
gnome-vfs model. 

> However, adding more dependencies to gnome-vfs, especially ones that
> are not already tied tot he GNOME release schedule, would be a
> pain.

I can understand this. Certainly an issue, but I would simply say that *if*
you're going to do it, then you've gotta deal with the issue at some point.
Probably easier to do sooner rather than later.

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

*) Digest authentication
*) HTTP/1.1 support: chunked transfer encoding, persistent connections
 [ note the above two are *required* by RFC 2518 (WebDAV) ]

*) SSL support
*) 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]

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'd also note that gnome-http has proxy support, but misses most of the
above also.

Well... I'm gonna stop evangelizing now :-) ... I think you've got all the
info that I can provide. It *is* your time to spend, and choice to make,
after all... I'm just hoping to save you time and increase functionality and
DAV-interop.

Cheers,
-g

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