[Top][All Lists]
[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
- [Arx-users] ArX server requirements (was: useful lib...), (continued)
- [Arx-users] ArX server requirements (was: useful lib...), Kevin Smith, 2004/12/10
- Re: [Arx-users] ArX server requirements, Walter Landry, 2004/12/11
- Re: [Arx-users] ArX server requirements, Kevin Smith, 2004/12/11
- Re: [Arx-users] ArX server requirements, Walter Landry, 2004/12/11
- Re: [Arx-users] ArX server requirements, Kevin Smith, 2004/12/11
- Re: [Arx-users] ArX server requirements, Walter Landry, 2004/12/11
Re: [Arx-users] useful lib..., Kevin Light, 2004/12/12
Message not available