Re: [ecf-dev] Event hierarchy confusion and problem

[Thomas Hallgren <thomas@xxxxxxx>]

Scott Lewis wrote:
> Yes.  The idea here is that the IIncomingFileTransfer instance is 
> returned from the receive method on 
> IIncomingFileTransferReceiveStart..because in some protocols the 
> methods exposed by IIncomingFileTransfer are not actually 
> available/valid until the receive method completes successfully (i.e. 
> returns a valid value/doesn't throw an exception).
OK, I suspected that.

> So I think the course of adding accessors for info that for some 
> providers is available prior to receive (i.e. on 
> IIncomingFileTransferReceiveStartEvent)...as per 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=223207 is probably the 
> way to go (allow the size and lastModified data to be accessed before 
> receive for those providers that support that/have that information).
If I read you correctly you mean that the methods getLength(), 
getRemoteName(), and getLastModified() should be added to the 
IIncomingFileTransferReceiveStartEvent rather then to the 
IIncomingFileTransfer?

Not sure I agree that that would be the best solution. I would in fact 
rather have the getSource() return null in case it's not available. If 
all I want is those values, that would give me a chance to do the following:

IIncomingFileTransfer src = event.getSource();
if(src != null)
  pickWantedValues(src);
else {
  // Ouch, no source until we start the transfer. So let's start it and 
then cancel
  // once we have the values that we want.
  src = event.receive(output stream to /dev/null);
  pickWantedValues(src);
  event.cancel();
}

>   Hopefully the lastModified and size will be enough, as it's not at 
> all clear to me that other meta-data will be available for other 
> transports.  One cop out might be to provide a Properties 
> getProperties() method on IIncomingFileTransferReceiveStartEvent but I 
> would like to resist that for the time being.
I can sympathize with that. Arbitrary properties will result in 
difficulties with backward compatibility as you go along. Clean 
interfaces is my preference too. One additional thing that comes to mind 
is the contentType but I have no use for it today.

- thomas