[Synotic]

Hi guys.

I am working on a project through my school that, in general terms, is a web application that lets faculty share their assets (largely images) with other faculty and students.

We have what I think is a fairly common problem: There is no simple way to get large amounts of assets onto the server. I've looked at what other websites are doing, and it seems that the consistent approach is to develop a desktop based FTP client, that is specific to that web application.

Thing is, my strength isn't writing desktop applications. I did write a personal Cocoa program or two a few years ago, but I was crummy at it and I hardly remember anything. From my initial research, it doesn't seem like it'd be too difficult to create. Take OmniGroup's OmniNetworking framework, with which they claim "writing a simple FTP client, or custom TCP/IP-based server program becomes a trivial task," and then hardcode a server into the code, then create a simple interface to let the user enter a login and password, and a list view where files can be dragged on and an upload button.

I know developers (myself included) hate it when people say something is simple and could be created in a few days, but in this case I think it's possible.

If any of you are familiar with a program that already does this (I found something like it for Mac OS 9) or are interested in developing something like it, let me know in this thread or PM me. I'd love to work with you and could work on interface design.

If this project does catch anyone's interest, then simply hardcoding the server name in the code would be a Good Enough™ first run. But I can foresee a more-developed application that would let a user generate any number of mini-FTP clients or even droplets for specific purposes. This would be useful outside of the scope of web applications and could just be a convenient way to throw files on a server without a full dedicated client.

[Chuckit]

I think it would be easier to make a REST-based server app. That way, you could make a Web interface for uploading things (cross-platform, baby!), and you could also have a very lightweight client that posted files using the REST API. Seems much simpler than creating a custom FTP client and server setup.

[mduell]

Why not use one of the many existing web-based content management systems?

[greenG4]

Originally Posted by mduell 

Why not use one of the many existing web-based content management systems?

Exactly. I use joomla with joomlaxplorer installed. There may be better options, though I've never really looked.

[Synotic]

Thanks for the replies everyone.

Chuckit: I am definitely open to different methods. I just did some preliminary research, and I'm having trouble figuring out exactly what it involves (I can't find a one-liner explanation on Wikipedia). I was able to glean that it's a means of decoupling the identified from the identifier, similar to OOP, where the implementation can be changed while maintaining a stable interface. That said, I'm not sure how I can apply this to my situation? When you say "client that posts files," do you mean a web-based client or a desktop-based client? Web-based file transfer is too limiting for anything more than a few files at a time. If it's a desktop client, wouldn't there be similar overhead and resources in creating an application?

I'm not trying to be contrarian, I'm just a little confused . You have piqued my interest though, and I've put RESTful Web Services on my reading list. It looks like a good book.

mduell: This is a pre-existing application that's been around for about three years. My job is to work with what's already there and try and solve some existing issues. From what I understand they spent a long time researching other solutions, and they've decided to stick with the current, in-house solution.

[besson3c]

If you want something quick and dirty, you could writeup a simple Unix script to shuttle files to and from machines as long as you don't need to play with Windows machines. This would be very easy if you are comfortable using Unix.

The web file upload option will only work well if the max upload size does not exceed what your web server is set to handle. This might be worth looking into. If you are using the PHP to process forms where you upload files, the PHP default is only 2 meg. This of course can be upped.

[Chuckit]

Originally Posted by Synotic 

Chuckit: I am definitely open to different methods. I just did some preliminary research, and I'm having trouble figuring out exactly what it involves (I can't find a one-liner explanation on Wikipedia). I was able to glean that it's a means of decoupling the identified from the identifier, similar to OOP, where the implementation can be changed while maintaining a stable interface. That said, I'm not sure how I can apply this to my situation? When you say "client that posts files," do you mean a web-based client or a desktop-based client?

Basically, the idea is that you have a URL where people can upload their files with HTTP POST requests. The requests can be made with a form in a Web browser, but it can just as well be done in a normal desktop application. That's the basic idea of REST — you have resources, and you can manipulate them just by making simple HTTP requests. Since pretty much anybody can send HTTP requests, that basically allows for any kind of front-end interface you can dream up.

Besson raises a good point to consider, though, about file sizes. I didn't think of it off the top of my head because I've never run up against my server's upload limit, but it might make a difference for you.