Category: interdubs

A client of mine has a shoot supervisor in Paris. He takes stills for an upcoming job and is posting them on his own ftp site. My client asked if he could use Interdubs instead. He could. There is the public upload function that can be enabled for a login. But right now it does not support creation of folders. And he shot thousands of images. That’s where unix comes in real handy: He had given us the access paramaters for his ftp site where he stores those images. Using wget it was a breeze to write a little script that works as a conduit it and puts those images on to the interdubs server. Now whatever he creates on his ftp server in Europe will be mapped automatically into Interdubs. So people can use the comment feature, see thumbnails, can copy content.

All those nice features that Interdubs has, but ftp naturally lacks. ftp is a great work horse. Kinda. It’s so simple (actually it isn’t even), let’s say it’s so widely in use that it will not go away to soon. So it’s only natural to support it, and work with it. Instead of forcing people to use something more advanced. And with solutions like todays hack they can have the best of both worlds: They don’t need to change the way that they work. And in the same time everybody can have the benefit of working with the best tools available.

But wait, wget stores unix files and interdubs keeps files in a database. Did I recompile wget with Interdubs support? Well, that would be possible, but would take a day. Nobody has a day on a shoot for a commercial. At some point a couple prospective clients said that they could only use Interdubs if they could upload content via ftp. So I wrote an ftp gateway. Same deal: I did not change the ftp source (yet). I just wrote a general filesystem to Interdubs Database mapping tool. Not many people use ftp to upload content into Interdubs: The web interface is way to nice for that purpose it seems. But have this conduit is still a great way to get any data quickly and consistently into Interdubs.

Interdubs hit another milestone: I just pushed code update number 500. One of the beauties of an internet application that you host is that the code can be changed easily. All clients always run the current version. Since all information of interdubs exists in a database it is pretty easy to update and change code. Users suggest things, and it is often quicker to just write the feature and see how it is been used. If it is not gets used then it will go away again. That is the other beauty of a web application: you can see exactly how people are using the application. When I develop the interdubs code I usually develop it in a test segment. Once it works, or at least I have convinced myself that it would, I publish or ‘push’ it all client segments. I wrote a little version control system for this, and one of the features is that it does count the updates that went live. And just now I did update number 500. Five hundred times I put my results out there to make Interdubs better. It’s fun. For me and for the people that use Interdubs. Seing your suggestions and ideas getting implemented is encouraging users to think what could be better. Most of what makes Interdubs so useful resulted from user feedback. I just put a platform out there that worked with what I thought would be good feature set to start with. The plan always was to develop Interdubs around the needs of the users. With thirteen different customers right now I get a very healthy mix of feature requests: The rule is that if two people from different companies ever asked for a feature or have a similar issue with an existing function the task instantly bubbles up in priority and gets done as quickly as possible. The other nice effect of those five hunderd updates is that new users have a much better time with backend interface then they used to a couple of months ago.