🚀 go-pugleaf

Hi Owen,

Owen Green wrote:
 
> Just to let you know that I am on it, but I'm juggling things a bit here, so
> it'll be as and when :)
> 
> From a first glance the problem /may/ be on the client side, but it's not so
> easy to see what's going on; the various responsibilities of the classes
> don't seem to be too strictly bounded, which makes things harder to follow -
> I'll crack it though ;)
> 
> Just a thouht, but is allowing the thread that's actually uploading to be
> suspended a good idea when its performing what amounts to socket IO?

You may have a point, however, at first I didn't see any reason not to.
I've coded
it so that the thread gets suspended only after it has done its job.  I
didn't see
any harm in that. 
 
> It strikes me that if you're going to allow pausing (why do you need it?),

As mentioned earlier, the way the scenario goes on the client side is: 

1)in uploadFile() create a File object
2)get the files size and transmit that value to the server app
3)the server app determines if there is enough space in the users home
directory
  to accomodate the file.
4)I need a mechanism on the client side to wait for the reply from the
server
  as to whether to proceed or not, thus the request_workerThread. It
will wait
  five second intervals, up to 30 seconds total for a reply. After 30
seconds, if there
  is no reply from the server, request_workerThread suspends itself
again
  until it is called.

  Otherwise, it gets the signal to "proceed" and performs the upload.
5)Upon completion of the upload, it suspends itself again.


> there should be a way of signalling this to the server, perhaps in the same
> way that FTP uses control messages (on a different socket).

I'm open to any suggestions as to how to do this in a better, more
efficient manner.
If you know of a better way I'd love to work with you on it.

Regards,

Alan