Re: [lwip-devel] FTP client

[Laurent GONZALEZ]

On 23/06/2014 15:11, Sergio R. Caprile wrote:

> Hi Laurent,
> I've been collecting some examples and ended up with an eCos client and
> a derivative. Both seem to be written for lwIP and not using the raw
> interface.
> I have plans to add such a client in the not so distant future, so I'm
> willing to cooperate on this task. I'm definitely biting more than I can
> chew in terms of simultaneous projects, so don't expect me to be a great
> help if you are in a hurry.

Sergio, this client is a requirement for a very short term project. Don't 
worry, any help will be appreciated even the smallest amount. The more eyes and 
hands there are on this code, the faster we will get maturity, this is good for 
the community, this is good for my project as well.

> Let's start coordinating our needs. Mine are:
> - raw interface
> - no OS (at all)
> - low memory footprint, both flash and RAM
> - PUT, GET can wait or even be absent
> - no need to have other commands except for BINARY and PASV (if I'm not
> missing something)
>
> My guidelines:
> - As there is no OS, there are no files.
> -- We can use the same "filesystem" interface from the httpdserver_raw
> for a pseudo file system, I have extended it to support authentication
> for my own fork of the server and plan to extend it more.
> -- Besides that, we'll also need a datahandler/callback to generate the
> info on the fly. This is handy when you have your logs or tables or data
> or whatever and need to upload them on a server as files. You browse
> your data and generate a report record by record while putting the file,
> this requires almost no memory, no file system, and gets the job done in
> an elegant way. This function is called (back) at transfer state, I have
> working examples from other platforms we can peek (not use). I plan
>
> I think this is the bare bones client I need and can be relatively easy
> to write. Let me know yours.

We share most of those points: I need a very light client, good enough to 
offload data from our tiny embedded devices to a server (with big GBs of 
space;). STOR being obviously of much higher priority than RETR command.
On the other side, I need this client for a system that has FreeRTOS. IMHO, the 
raw API makes possible to design the client to be agnostic to the presence of 
an OS.
Moreover, my target system has FatFs. Again, it should be possible to abstract 
data flow, so that everyone can use the storage he/she likes.
My goal is to design for everyone: with or without OS, with or without FS. Of 
course my priority being FreeRTOS+FatFS, I will first focus on it and allocate 
only a reasonable amount of time to the one-size-fits-all design.

> I would use Simon's SMTP client as a skeleton and the collected FTP
> clients as a reference. I will send you those by pm if you agree.

E-mail me only URL, when possible, otherwise send me the bulk ;)

> We can setup a CVS/SVN/git tree somewhere and cooperate, I'm more
> proficient with CVS and SVN, but can use git. When we have something
> working, we can submit to this list and wait for it to be added (or
> not), but serve it somewhere in the meantime.

Git is cool. I can provide space of my own, but I think using GitHub makes 
sense.

> We can then keep our traffic off the list, if someone else is interested
> can post on this thread and we'll give directions. Do you agree ?
>
Let's go. I will start by the end of this week, first commit probably this WE.

--

GONZALEZ Laurent