arx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Arx-users] useful lib...


From: Walter Landry
Subject: Re: [Arx-users] useful lib...
Date: Mon, 13 Dec 2004 22:04:10 -0500 (EST)

Amine Chadly <address@hidden> wrote:
> Hello everybody,

I assume that you meant to send this to the list.

> [snips all over ... ;-]
> 
> >I considered curl when I was looking at networking libraries.
> >Unfortuntately, curl does not support sftp.  That is a deal-breaker
> >for me, since that is probably the only protocol I really use.
> >However, there is silc
> >
> >  http://silcnet.org/docs/toolkit/silcsftplib.html
> >
> >But then I would have to deal with three different possibilities:
> >local, networked non-sftp, networked sftp.  With gnome-vfs local and
> >remote are the same.  Plus it has the added benefit of all of the
> >wacky protocols that gnome-vfs supports.
> >  
> >
> Libcurl does limit its support on the ftp front to ftps... I had a look 
> to silcnet.org, and
> it looks promissing and a little bit complicated ;-).
> 
> >An interesting thing to do would be to just replace gnome-vfs with
> >boost::filesystem.  You will have to do some hacking in
> >boost::filesystem because I have modified it to use hard links.  After
> >that, and fixing up the files you mention (the only problem is that
> >they call chmod), everything should, in theory ;), work.
> >
> 
> If I understand what you wrote correctly, all local calls made
> through gnome-vfs should be replaced by boost call, while the
> retreiving of remote files shall be done using whatever library we
> end up using right ?

Yes.

> I am wondering if we could not have some kind of abstraction level
> that would encapsulate filesystem calls.

That would be the interface exposed by src/arx/include/gvfs.hpp. So
you need equivalents for

  fill_directory_list
  Init
  exists
  is_directory
  is_link
  make_directory
  copy
  remove
  out_file
  in_file
  read_file_into_string

write_archive, read_archive, and remove_all are defined in terms of these.

> The underlaying library could be chosen at compile time according to
> availability and platform concerns.  That implies extra coding work,
> but would make ArX more flexible regarding a critical point
> (portability) ?

Yes.

> If you agree with the idea, I am willing to dig in that direction
> under your supervision, as soon as I manage to get a internet
> connection at home (I am hoping to get this before next year :-) .

Sounds great.  The first thing you should do is just get local stuff
working with boost.  That should be enough to have a working pure
win32 port.  Then you can add in the libraries (curl, silc, neon).

> >As an aside, I have done some work on the getting ArX working under
> >Cygwin.  It compiles and I can run through parts of the test suite,
> >but I am having problems running "fork".  So I feel I am getting close.
> >
> 
> Groovy, this is good news ! Thanks for your continuous hard work :-)
>  -amine

Walter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]