[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Event hierarchy confusion and problem
|
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