Viewing internal Queue

Question

Is there a way to get whats on the transfer queue if multiple BeginDownload or the multiple/folder versions are called? By that I mean say we opt to download the entire "Work" folder, the internal queue to determine whats coming up next?

Answer 1

No there aren't yet, though we have considered adding it previously. While we could add it fairly soon, I can't promise you that we can add it in the next few days since we are heavily occupied with other development work at the moment.

- Hans (EnterpriseDT)

Answer 2

Hi,

Nope thats quite OK, I can leave that on the back burner. I'm just writing up and R&D'ing your product and making a proposal comparing it to another to put forward to management. Thus far it appears yours is exceeding our expectations (with the issue with slow Ftp over SSH being a primary con at this point). So even if its sometime next month its fine :-)

Thanks for the note though.

Answer 3

I'm sure we can get it to you some time next month. I'll put it in our calendar, but feel free to send us a hurry-up next month if you haven't heard from us by then.

- Hans (EnterpriseDT)

Answer 4

count++;

for the feature request :-) I've been manually queuing things because I cant peek into the internal Queue.

How do you plan on giving access to the Queue?

And theres also no rush on my end but sometime within the next couple of months would be el-grande 8)

Answer 5

You've probably noticed that IAsyncResult is returned by each of the asynchronous methods. The class that implements this interface is currently private and is used for our internal queue only. It fully describes the operation that is to be executed asynchronously, so it contains the following:

• the state object that was passed in.
• the AsyncCallback delegate that was passed in.
• a back-reference to the connection object.
• a MethodInfo for the synchronous method to be called (e.g. if you called BeginDownloadFile then this would be for DownloadFile)
• the arguments that are to be passed in when the MethodInfo is invoked.
• a few of other things related to the IAsyncResult interface and to the return value or exception.

I expect that we should be able to expose this class and provide some properties for accessing its members. We would then also provide a method for accessing the collection of all these objects which represent the operations that are currently queued.

What I'm not sure about at the moment is (1) if this is all the information you require, and (2) in what form you would like the information. In particular, providing access to the MethodInfo object itself is very easy for us, but perhaps it's not that useful for you. What do you think? I'm very interested to hear your thoughts so please don't hold back (I mean both of you - and anyone else for that matter). :)

- Hans (EnterpriseDT)

Answer 6

Howdy,

I guess this would be a start, whilst the MethodInfo is useful to workout what the 'work item' its about to do.

What I'm trying to accomplish is basically a queing system for transfering files (down/up) - I sent a screenshot of what our product looks like to Bruce by email - but at the moment I've got a synchronised Queue that sits there (actually its a List so its possible to remove items and reorder etc) and a different thread picks up a work item and carries it out (Publisher-Consumer pattern style using waits/signals). But this functionality is already built into edt (but for all operations).

What I'm concerned about is the multi-transfers, in the case of where you upload or download an entire folder structure, is there a way of knowing whats queued to download or upload? Maybe to cancel a pending operation (rather than Abort all Sync transfers). It gets tricky and I'm not sure if its up to you to implement it fully, but I'm just a bit unsure when I cant see whats on the queue before I call a method.

I'll get back to you on this as I havent touched our stuff since Thursday.

Answer 7

hi guys,

sorry i was on annual leave :(

for our purposes we need to see whats in the queue and the ability to remove an item - a user would need to sometimes - or to move the priority of the task to be first etc - something like the synchronizing queue thushan mentioned.

some of our sales/accounting staff grab an entire folder of stuff, but find later on in their infinite wisdom that they dont need 95% of the gunk and endup cancelling the transfers one by one (go figure!). So we'd like them to continue bashing their heads in and following this procedure until they realise they can just pick the items they *need* to grab instead.