Recent events at work have shown a need to replace/re-invent our delivery system for Work In Progress (hereafter WIP), which is presently being achieved with FTP.
This meditation will be a long one, and I assure the reader that perl is involved - in synopsis "A perl CGI content manager coupled with FTP virtual users , providing both FTP and HTTP interfaces to the same userdata, optionally HTTP is enriched with meta-data like comments, descriptions, thumbnails."
We are a video/film postproduction facility , providing services like color-grading , 3d animation, editing , visual effects ,etc. So our product is moving pictures. Much of our work is from overseas, and often most of the initial direction and feedback is done remotely. ie We courier a tape , or post an mpeg to our FTP site, client reviews the material and responds with comments and direction.
This presents a number of issues that interrupt or dis-enchant our clients from using the service. The idea is that remote clients can be delivered WIP more frequently by downloading it across the net. Sadly it would seem they're quite unwilling to use FTP client software and 99.9% of the time use a web browser, so I find myself giving up providing username, password and hostname ; instead opting for ftp://clientname:firstname.lastname@example.org and emailing the (awful) link to the remote client. I will not begin to explain all the ways the IE is not an FTP client, nor how many companies now deny access to those fabulous port 20,21 outgoing connects. Suffice it to say that despite being the most efficient transport for the task, FTP is unsuitable for the point and clickers at the recieving end. (I'm biting my tounge whilst writing this - can you tell?).
After much rumination and procrastination, I believe there is a solution that will
- Provide a client-friendly interface to WIP data
- Support FTP upload/download just like we always have, for the net-literate
- Foster even better (easier) communication
- Be more attractive to clients and prospective clients
- Keep me from growing bored unjamming printers 9-5
I'm joking of course on that last one - I love printers - really.
I'm glad you asked! I am aware of several content engines but suspect that when production hand down their specification (they're brewing it right now), it will be so specific that a home-grown , roll your own solution may be the best way to go.
My plan is to use an ftpd that supports virtual users and can authenticate to a database , this takes care of 'keeping it like it is' for the true ftp clients and other facilities who prefer it. For the web interface, I would like to use perl CGI to authenticate to the same database, also storing user session objects and content metadata in the DB.
Thus far I have prototyped the session mechanism using PureFTPD (with --use-ldap) , openldap (with some custom schema) , and everyone's hero perl and a multitude of modules like Net::LDAP , Digest::MD5, HTML::Template and naturally, CGI.pm (you didn't think I'd roll that my self did you!).
I would love to see some debate on the validity of this solution, comments from monks who have travelled this road, FUD aswell since I have no doubt there are some traps awaiting me and foreknowledge is a wonderful thing
Many thanks to you for getting through the readmore I eagerly await the monastic gestalt.
Cheers! - toaster.
I can't believe it's not psellchecked