Hello Monks,

A handful of free services on the Net are offering free "online hard drives" (I will leave it as an exercise to the reader to check out the specifics of the offers each entity makes). To make a short list, there is:

As a user I find a lot to be annoyed about concerning all these sites -- but they are free, after all, so complaining about their buggy systems is pretty pointless. However as a coder I am not satisfied to leave it alone; I cannot help but wonder if there isn't a challenge to be met there. If their coders cannot get their sites to work, maybe I can overcome the obstainancy of their systems with some judiciously applied Perl?

Just for reference, because some readers may wonder what I mean by "buggy", I'll observe that file uploads often fail. It may be that some of these services (I have accounts with them all <sigh> ..) have file size limits that I forget in between each time I need to upload (and I'd like to arrange for someone reliable, like Perl, to remember that kind of thing for me ... wouldn't this be true laziness ?) Also the desktop client software for Win32 that can be downloaded for most of the services is not working on WinNT (even though it is supposed to -- a situation that many NT users must find quite tiresomely familiar; it is an industry-wide problem with mass-marketed commercial software).

My meditation concerns this: an invitation to

  1. Let us know if anyone knows of existing Perl hacks into these systems, so that uploading or downloading of files from the remote storage server can be programmatically controlled;
  2. Let us know if anyone has been thinking about this, but hasn't written any working code yet;
  3. Let us (me specifically) know if the idea interests any fellow monks and they would like to collaborate on a project.

For my part I have little detailed knowledge of how these systems work, and don't want to assume without knowing more than I do, and I think that hacking this all by myself is a bit beyond my abilities at present. However I recently came across a clue that suggested to me that xdrive, for instance, is simply using a variety of FTP transaction (as might well all of them be) to upload to the remote server.

My guess is that this would be true "hacking" as the clueless mass media knows it, involving the running of a packet sniffer on one's system to monitor and suss out what is taking place between one's desktop / laptop box and the remote server, and then seeking to construct a workable emulation of that in Perl, adding all sorts of error-checking, redundancy and try-again-until-it-uploads obstinancy of course. I have never used a packet sniffer. A sockets guru might find this a worthy game?

I would welcome any replies, insights, or expressions of interest.


    soren

Replies are listed 'Best First'.
(Some pointers for Web access) RE: A little project - Web storage
by Corion (Patriarch) on Aug 10, 2000 at 12:08 UTC

    Personally, I haven't heard of any such projects or truly portable clients other than your webbrowser for those services.

    I've looked at some of these services, namely iDrive and Freespace. Both of them use Javascript and cookies to present the files and store your login information, and iDrive uses the https protocol. All of these issues should be taken care of by the LWP module. Writing the actual code to parse out the directory contents and manipulate them will be tough work, as you will have to design an uniform interface to these services.

    I'm sorry to desillusion you, but the only "true" hacking taking place would be in staring at some Javascript embedded in some HTML to extract the filenames and file URLs from there :)

       by Corion:

      Personally, I haven't heard of any such projects or truly
      portable clients other than your webbrowser for those services.
      I've looked at some of these services, namely iDrive
      and Freespace. Both of them use Javascript and cookies to
      present the files and store your login information, and 
      iDrive uses the https protocol. All of these issues should be taken care of
      by the LWP module. Writing the actual code to parse
      out the directory contents and manipulate them will be
      tough work, as you will have to design an uniform interface
      to these services.

      I'm sorry to desillusion you, but the only "true" hacking
      taking place would be in staring at some Javascript embedded
      in some HTML to extract the filenames and file URLs from there :)

      Thanks for your reply, Corion.

      While it is true that the main way to interact with those services is through the Web browser (rather narrow range of recent ones that those services "support"), in fact several of them (<CITE>xdrive</CITE>, <CITE>freediskspace</CITE>) have downloadable applications that, once installed to the user's Windoze system, allow the remote storage area to appear as a "virtual hard drive" mapped to a drive letter for 'doze. This takes place purely outside of one's browser, in fact the browser does not even have to be running.

      LWP would be the way to go for sure if one was going to try to simulate the client-server interaction that takes place when one is doing the ordinary Web-based transfers. However the alternate method that these downloadable apps suggest is possible, could also be implemented in Perl, and would possibly be lower-level hacking than using LWP.

      soren

        Actually, I have my doubts that someone who already has a working interface (http), would go out and create yet another interface for the sake of better access. My guess is that those downloadable applications and explorer shell extensions are http clients as well, although they might access special pages, not unlike the special pages here at Perlmonks for the Chatterbox clients. But I really doubt that it would be of any benefit to go away from the http protocol (OK, maybe to ftp), either speed/performance wise or development wise.

        But even though you make derogatory remarks about Windows, you seem still to use it ("for the games" I hear them say), so you will have most likely ZoneGate installed, a firewall, that can also tell you quite a lot about incoming and outgoing TCP/IP connections. I suggest you take a short look with that one running and then maybe have a peek with a network sniffer - and be prepared to find http inside. :)