Re: [Arx-users] The Future (long)

[Walter Landry]

Catatonic Porpoise <address@hidden> wrote:
> Kevin Smith <address@hidden> wrote:
> 
> 
>  >>> > * No extra directories: (Subversion has .svn subdirectories in every
>  >>> >   directory, most other systems have a single special directory 
> at the
>  >>> >   top, and svk has no special directories, instead keeping that
>  >>> >   information elsewhere)
>  >>> >   -
>  >>> >   There is still a _arx directory at the top of every project tree.
>  >
>  >>
>  >> The bzr folks recently debated using . or _ for this. The big advantage
>  >> of .arx would be that tools like grep wouldn't recurse into the arx
>  >> metadata.
> 
> 
> This is a really good point -- however, I still think it's better not to
> start the directory with a dot, so that it shows up in directory
> listings, making it easy to see whether a tree is versioned.
> 
> As a compromise, perhaps the directory could start with an underscore,
> but the files and directories inside with a dot? Then grep(1) and
> friends wouldn't find anything interesting.

grep does recurse into directories that start with a dot.

  $ mkdir foo
  $ mkdir .foo
  $ echo "bar" > foo/bar
  $ echo "bar" > .foo/bar
  $ grep -r bar .
  ./foo/bar:bar
  ./.foo/bar:bar

However, 

  $ grep -r bar *
  foo/bar:bar

So making the _arx subdirectories into dots would definitely not help.
Changing _arx to .arx would help a little, but I do like it that it is
visible.  There doesn't seem to be a clear consensus whether the
directory should be hidden or not.

> Changing the subject, will ArX 3.0 do anything about the library bloat
> issue? The main reason I'm not using ArX right now is unwillingness to
> install gnome-vfs, orbit, glib, etc. It would be nice if ArX only
> depended on libraries that were fairly "light."

I have certainly been thinking about it.  The short answer is that
replicating the functionality actually requires a number of libraries.
>From my TODO

* libcurl + libssh, or python with paramiko?  Need sftp, http, ftp.
   Would really like webdav, ftps, https.

  libcurl: http, https, ftp, ftps -- needs openssl or gnutls
  neon: webdav  -- needs openssl and XML parser (expat, expat-lite,
   libxml, libxml2)
  libssh: ssh, sftp  -- needs openssl, still rough, not completely
   working on windows.

  libsoup: only http, https?

  paramiko: ssh, sftp
  python's urllib: Doesn't handle passwords in a standard way?  bzr
   just gives up.  A lot of people use rsync.  Bah.

  QUrlOperator: filesystem, http, ftp
  KDE: still rough on windows. not clear if everything is ported.  May
   require runtime support?  Maybe easier to just get gnome-vfs
   working?

  Maybe stay with gnome-vfs, since it seems like it is already being
   ported by the evolution hackers (Tor Lillqvist in particular).

Part of the rationale for moving to a non-gnomevfs solution was that
we could create monolithic Windows executables.  It may now be
possible to do so with gnome-vfs.  I have to do more checking.

However, I am aware that the gnome-vfs dependency is troublesome.

Cheers,
Walter