Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Communications Framework (ECF) » Receiving a file with FileShare
Receiving a file with FileShare [message #606365] Tue, 25 July 2006 13:59 Go to next message
Jaap Reitsma is currently offline Jaap ReitsmaFriend
Messages: 69
Registered: July 2009
Member
Hi,

Now we managed to send a file to the server, w'd like to receive it and do
something useful with it. In our case we simply want a peer-to-peer file
transfer.

I suppose we've got to provide a sub class of BaseFileShareReceiver and
override the receive method. This receive method uses however a packaged
scoped argument FileShareMessage. That is incorrect, right? I think it
should be a public class.

Should the (subclass of) BaseFileShareReceiver contain the reference to e.g.
an outputstream for saving the file? How is the transaction result reported
to this receiver?

Kind regards,

Jaap
Re: Receiving a file with FileShare [message #606369 is a reply to message #606365] Tue, 25 July 2006 19:00 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Jaap,

This is cool! You just jumped ahead...and you've pretty much defined
the needed changes I referred to in my posting of this morning (need to
provide a way to override/change/more flexibly define the receive
behavior).

RE: should the subclass of BaseFileShareReceiver contain the reference
to the outputstream...? Yes, for now. BaseFileShareReceiver can
provide this directly, but it doesn't yet, so for the time being
subclasses must. Note that if you create a BaseFileShareReceiver
subclass you must also override the code in
BaseFileShareSender.getReplicaDescription(...) so that the proper class
is specified (your subclass).

RE: transaction result...AbstractSharedObject subclasses have a method:

protected void creationCompleted()

that is called when the transaction/creation has completed successfully.
If the transaction is aborted, the BaseFileShareReceiver will be
destroyed. If it succeeds, the creationCompleted() will be called.

Thanks for your patience...there's more impl work to be done here, but
it's great to have a specific use case driving it.

Scott

Jaap Reitsma wrote:
> Hi,
>
> Now we managed to send a file to the server, w'd like to receive it and do
> something useful with it. In our case we simply want a peer-to-peer file
> transfer.
>
> I suppose we've got to provide a sub class of BaseFileShareReceiver and
> override the receive method. This receive method uses however a packaged
> scoped argument FileShareMessage. That is incorrect, right? I think it
> should be a public class.
>
> Should the (subclass of) BaseFileShareReceiver contain the reference to e.g.
> an outputstream for saving the file? How is the transaction result reported
> to this receiver?
>
> Kind regards,
>
> Jaap
>
>
Re: Receiving a file with FileShare [message #607465 is a reply to message #606369] Tue, 25 July 2006 20:33 Go to previous messageGo to next message
Jaap Reitsma is currently offline Jaap ReitsmaFriend
Messages: 69
Registered: July 2009
Member
Hi Scott,

Bleeding edge technology, that is what it is ;-)

How should an error be reported back to the sender? I suppose a
FileShareMessage(Exception) must be passed back, but how? Through a separate
channel?

I noted that besides listening for a creationCompleted one can inspect the
FileShareMessage because of the isDone flag.

Another question: How does the receiver know the file name? Currently we use
(abuse) the property map for sending the filename, is there another way?

Kind regards,

Jaap

"Scott Lewis" <slewis@composent.com> wrote in message
news:44C66A5B.3090409@composent.com...
> Hi Jaap,
>
> This is cool! You just jumped ahead...and you've pretty much defined the
> needed changes I referred to in my posting of this morning (need to
> provide a way to override/change/more flexibly define the receive
> behavior).
>
> RE: should the subclass of BaseFileShareReceiver contain the reference to
> the outputstream...? Yes, for now. BaseFileShareReceiver can provide
> this directly, but it doesn't yet, so for the time being subclasses must.
> Note that if you create a BaseFileShareReceiver subclass you must also
> override the code in BaseFileShareSender.getReplicaDescription(...) so
> that the proper class is specified (your subclass).
>
> RE: transaction result...AbstractSharedObject subclasses have a method:
>
> protected void creationCompleted()
>
> that is called when the transaction/creation has completed successfully.
> If the transaction is aborted, the BaseFileShareReceiver will be
> destroyed. If it succeeds, the creationCompleted() will be called.
>
> Thanks for your patience...there's more impl work to be done here, but
> it's great to have a specific use case driving it.
>
> Scott
>
> Jaap Reitsma wrote:
>> Hi,
>>
>> Now we managed to send a file to the server, w'd like to receive it and
>> do something useful with it. In our case we simply want a peer-to-peer
>> file transfer.
>>
>> I suppose we've got to provide a sub class of BaseFileShareReceiver and
>> override the receive method. This receive method uses however a packaged
>> scoped argument FileShareMessage. That is incorrect, right? I think it
>> should be a public class.
>>
>> Should the (subclass of) BaseFileShareReceiver contain the reference to
>> e.g. an outputstream for saving the file? How is the transaction result
>> reported to this receiver?
>>
>> Kind regards,
>>
>> Jaap
Re: Receiving a file with FileShare [message #607466 is a reply to message #607465] Tue, 25 July 2006 21:14 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Jaap,

Jaap Reitsma wrote:
> Hi Scott,
>
> Bleeding edge technology, that is what it is ;-)

Gotta start somewhere :)

>
> How should an error be reported back to the sender? I suppose a
> FileShareMessage(Exception) must be passed back, but how? Through a separate
> channel?


Probably do need to add a message from receiver back to sender (for
exceptions and canceling.

>
> I noted that besides listening for a creationCompleted one can inspect the
> FileShareMessage because of the isDone flag.
>
> Another question: How does the receiver know the file name? Currently we use
> (abuse) the property map for sending the filename, is there another way?


In the IFileShareContainer.createSender API there is already a parameter
'remoteTarget' type ID. My intention was to pass this through to the
BaseFileShareSender (the generic provider impl in FileShareContainer
doesn't do this right now), and then allow BaseFileShareSender and/or
any subclasses to use this value to determine the appropriate local
path/name and location on file system. It currently doesn't pass
remoteTarget through to the BaseFileShareSender...but that can/will be
easily fixed.

In the mean time, using properties should work just fine.

Thanks,

Scott
Re: Receiving a file with FileShare [message #607469 is a reply to message #607465] Wed, 26 July 2006 05:08 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Jaap,

I added some code to BaseFileShareSender and BaseFileShareReceiver to

1) allow subclasses to easily override some of the default behaviors for
sending/receiving (e.g. see fields that are now protected rather than
default)
2) BaseFileShareSender is now passed the 'remoteTarget' ID specified as
a IFileShareContainer.createSender parameter, and this ID is added to
the properties replicated to the BaseFileShareReceivers
3) BaseFileShareReceiver retrieves the given property from '2', if
non-null, and sets a new instance variable 'localTarget' that specifies
the receiver's *suggested* local target
4) In BaseFileShareReceiver.receive method, if localTarget is non-null,
a FileOutputStream with the name specified via the result of the
BaseFileShareReceiver.receiveAndSaveToFile
5) the data from the message is then saved to the new FileOutputStream,
effectively saving the file.

This still isn't optimal for the BaseFileShareReceiver, as receiver
subclasses sometimes will want to allow the user to specify the target
file rather than using the 'localTarget' ID passed by the sender (really
just a suggested name, as the receiver can do whatever it wishes with
the data in terms of storage on local file system.

In any event, hopefully this will be more useful to your team and others.

Scott


Jaap Reitsma wrote:
> Hi Scott,
>
> Bleeding edge technology, that is what it is ;-)
>
> How should an error be reported back to the sender? I suppose a
> FileShareMessage(Exception) must be passed back, but how? Through a separate
> channel?
>
> I noted that besides listening for a creationCompleted one can inspect the
> FileShareMessage because of the isDone flag.
>
> Another question: How does the receiver know the file name? Currently we use
> (abuse) the property map for sending the filename, is there another way?
>
> Kind regards,
>
> Jaap
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:44C66A5B.3090409@composent.com...
>> Hi Jaap,
>>
>> This is cool! You just jumped ahead...and you've pretty much defined the
>> needed changes I referred to in my posting of this morning (need to
>> provide a way to override/change/more flexibly define the receive
>> behavior).
>>
>> RE: should the subclass of BaseFileShareReceiver contain the reference to
>> the outputstream...? Yes, for now. BaseFileShareReceiver can provide
>> this directly, but it doesn't yet, so for the time being subclasses must.
>> Note that if you create a BaseFileShareReceiver subclass you must also
>> override the code in BaseFileShareSender.getReplicaDescription(...) so
>> that the proper class is specified (your subclass).
>>
>> RE: transaction result...AbstractSharedObject subclasses have a method:
>>
>> protected void creationCompleted()
>>
>> that is called when the transaction/creation has completed successfully.
>> If the transaction is aborted, the BaseFileShareReceiver will be
>> destroyed. If it succeeds, the creationCompleted() will be called.
>>
>> Thanks for your patience...there's more impl work to be done here, but
>> it's great to have a specific use case driving it.
>>
>> Scott
>>
>> Jaap Reitsma wrote:
>>> Hi,
>>>
>>> Now we managed to send a file to the server, w'd like to receive it and
>>> do something useful with it. In our case we simply want a peer-to-peer
>>> file transfer.
>>>
>>> I suppose we've got to provide a sub class of BaseFileShareReceiver and
>>> override the receive method. This receive method uses however a packaged
>>> scoped argument FileShareMessage. That is incorrect, right? I think it
>>> should be a public class.
>>>
>>> Should the (subclass of) BaseFileShareReceiver contain the reference to
>>> e.g. an outputstream for saving the file? How is the transaction result
>>> reported to this receiver?
>>>
>>> Kind regards,
>>>
>>> Jaap
>
>
Re: Receiving a file with FileShare [message #607471 is a reply to message #607469] Wed, 26 July 2006 08:06 Go to previous messageGo to next message
Jaap Reitsma is currently offline Jaap ReitsmaFriend
Messages: 69
Registered: July 2009
Member
Hi Scott,

Thanks for the effort, we'll check it out. I will keep you in touch with our
progress. When will the next release be made available?

As earlier noted, don't forget to give FileShareMessage public scope as
opposed to package which it is now (cvs version1.2). This class is used as
an argument in the protected method BaseFileShareReceiver.receive().

Kind regards,

Jaap

"Scott Lewis" <slewis@composent.com> wrote in message
news:44C6F8B2.7050904@composent.com...
> Hi Jaap,
>
> I added some code to BaseFileShareSender and BaseFileShareReceiver to
>
> 1) allow subclasses to easily override some of the default behaviors for
> sending/receiving (e.g. see fields that are now protected rather than
> default)
> 2) BaseFileShareSender is now passed the 'remoteTarget' ID specified as a
> IFileShareContainer.createSender parameter, and this ID is added to the
> properties replicated to the BaseFileShareReceivers
> 3) BaseFileShareReceiver retrieves the given property from '2', if
> non-null, and sets a new instance variable 'localTarget' that specifies
> the receiver's *suggested* local target
> 4) In BaseFileShareReceiver.receive method, if localTarget is non-null, a
> FileOutputStream with the name specified via the result of the
> BaseFileShareReceiver.receiveAndSaveToFile
> 5) the data from the message is then saved to the new FileOutputStream,
> effectively saving the file.
>
> This still isn't optimal for the BaseFileShareReceiver, as receiver
> subclasses sometimes will want to allow the user to specify the target
> file rather than using the 'localTarget' ID passed by the sender (really
> just a suggested name, as the receiver can do whatever it wishes with the
> data in terms of storage on local file system.
>
> In any event, hopefully this will be more useful to your team and others.
>
> Scott
>
>
> Jaap Reitsma wrote:
>> Hi Scott,
>>
>> Bleeding edge technology, that is what it is ;-)
>>
>> How should an error be reported back to the sender? I suppose a
>> FileShareMessage(Exception) must be passed back, but how? Through a
>> separate channel?
>>
>> I noted that besides listening for a creationCompleted one can inspect
>> the FileShareMessage because of the isDone flag.
>>
>> Another question: How does the receiver know the file name? Currently we
>> use (abuse) the property map for sending the filename, is there another
>> way?
>>
>> Kind regards,
>>
>> Jaap
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:44C66A5B.3090409@composent.com...
>>> Hi Jaap,
>>>
>>> This is cool! You just jumped ahead...and you've pretty much defined
>>> the needed changes I referred to in my posting of this morning (need to
>>> provide a way to override/change/more flexibly define the receive
>>> behavior).
>>>
>>> RE: should the subclass of BaseFileShareReceiver contain the reference
>>> to the outputstream...? Yes, for now. BaseFileShareReceiver can
>>> provide this directly, but it doesn't yet, so for the time being
>>> subclasses must. Note that if you create a BaseFileShareReceiver
>>> subclass you must also override the code in
>>> BaseFileShareSender.getReplicaDescription(...) so that the proper class
>>> is specified (your subclass).
>>>
>>> RE: transaction result...AbstractSharedObject subclasses have a method:
>>>
>>> protected void creationCompleted()
>>>
>>> that is called when the transaction/creation has completed successfully.
>>> If the transaction is aborted, the BaseFileShareReceiver will be
>>> destroyed. If it succeeds, the creationCompleted() will be called.
>>>
>>> Thanks for your patience...there's more impl work to be done here, but
>>> it's great to have a specific use case driving it.
>>>
>>> Scott
>>>
>>> Jaap Reitsma wrote:
>>>> Hi,
>>>>
>>>> Now we managed to send a file to the server, w'd like to receive it and
>>>> do something useful with it. In our case we simply want a peer-to-peer
>>>> file transfer.
>>>>
>>>> I suppose we've got to provide a sub class of BaseFileShareReceiver and
>>>> override the receive method. This receive method uses however a
>>>> packaged scoped argument FileShareMessage. That is incorrect, right? I
>>>> think it should be a public class.
>>>>
>>>> Should the (subclass of) BaseFileShareReceiver contain the reference to
>>>> e.g. an outputstream for saving the file? How is the transaction result
>>>> reported to this receiver?
>>>>
>>>> Kind regards,
>>>>
>>>> Jaap
>>
Re: Receiving a file with FileShare [message #607472 is a reply to message #607471] Wed, 26 July 2006 13:38 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Jaap,

Jaap Reitsma wrote:
> Hi Scott,
>
> Thanks for the effort, we'll check it out. I will keep you in touch with our
> progress. When will the next release be made available?


Haven't decided, but it could be either

a) next Monday (31) or
b) following Monday (7).


>
> As earlier noted, don't forget to give FileShareMessage public scope as
> opposed to package which it is now (cvs version1.2). This class is used as
> an argument in the protected method BaseFileShareReceiver.receive().


OK thanks. Changed and checked in.


Scott


>
> Kind regards,
>
> Jaap
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:44C6F8B2.7050904@composent.com...
>> Hi Jaap,
>>
>> I added some code to BaseFileShareSender and BaseFileShareReceiver to
>>
>> 1) allow subclasses to easily override some of the default behaviors for
>> sending/receiving (e.g. see fields that are now protected rather than
>> default)
>> 2) BaseFileShareSender is now passed the 'remoteTarget' ID specified as a
>> IFileShareContainer.createSender parameter, and this ID is added to the
>> properties replicated to the BaseFileShareReceivers
>> 3) BaseFileShareReceiver retrieves the given property from '2', if
>> non-null, and sets a new instance variable 'localTarget' that specifies
>> the receiver's *suggested* local target
>> 4) In BaseFileShareReceiver.receive method, if localTarget is non-null, a
>> FileOutputStream with the name specified via the result of the
>> BaseFileShareReceiver.receiveAndSaveToFile
>> 5) the data from the message is then saved to the new FileOutputStream,
>> effectively saving the file.
>>
>> This still isn't optimal for the BaseFileShareReceiver, as receiver
>> subclasses sometimes will want to allow the user to specify the target
>> file rather than using the 'localTarget' ID passed by the sender (really
>> just a suggested name, as the receiver can do whatever it wishes with the
>> data in terms of storage on local file system.
>>
>> In any event, hopefully this will be more useful to your team and others.
>>
>> Scott
>>
>>
>> Jaap Reitsma wrote:
>>> Hi Scott,
>>>
>>> Bleeding edge technology, that is what it is ;-)
>>>
>>> How should an error be reported back to the sender? I suppose a
>>> FileShareMessage(Exception) must be passed back, but how? Through a
>>> separate channel?
>>>
>>> I noted that besides listening for a creationCompleted one can inspect
>>> the FileShareMessage because of the isDone flag.
>>>
>>> Another question: How does the receiver know the file name? Currently we
>>> use (abuse) the property map for sending the filename, is there another
>>> way?
>>>
>>> Kind regards,
>>>
>>> Jaap
>>>
>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>> news:44C66A5B.3090409@composent.com...
>>>> Hi Jaap,
>>>>
>>>> This is cool! You just jumped ahead...and you've pretty much defined
>>>> the needed changes I referred to in my posting of this morning (need to
>>>> provide a way to override/change/more flexibly define the receive
>>>> behavior).
>>>>
>>>> RE: should the subclass of BaseFileShareReceiver contain the reference
>>>> to the outputstream...? Yes, for now. BaseFileShareReceiver can
>>>> provide this directly, but it doesn't yet, so for the time being
>>>> subclasses must. Note that if you create a BaseFileShareReceiver
>>>> subclass you must also override the code in
>>>> BaseFileShareSender.getReplicaDescription(...) so that the proper class
>>>> is specified (your subclass).
>>>>
>>>> RE: transaction result...AbstractSharedObject subclasses have a method:
>>>>
>>>> protected void creationCompleted()
>>>>
>>>> that is called when the transaction/creation has completed successfully.
>>>> If the transaction is aborted, the BaseFileShareReceiver will be
>>>> destroyed. If it succeeds, the creationCompleted() will be called.
>>>>
>>>> Thanks for your patience...there's more impl work to be done here, but
>>>> it's great to have a specific use case driving it.
>>>>
>>>> Scott
>>>>
>>>> Jaap Reitsma wrote:
>>>>> Hi,
>>>>>
>>>>> Now we managed to send a file to the server, w'd like to receive it and
>>>>> do something useful with it. In our case we simply want a peer-to-peer
>>>>> file transfer.
>>>>>
>>>>> I suppose we've got to provide a sub class of BaseFileShareReceiver and
>>>>> override the receive method. This receive method uses however a
>>>>> packaged scoped argument FileShareMessage. That is incorrect, right? I
>>>>> think it should be a public class.
>>>>>
>>>>> Should the (subclass of) BaseFileShareReceiver contain the reference to
>>>>> e.g. an outputstream for saving the file? How is the transaction result
>>>>> reported to this receiver?
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Jaap
>
Previous Topic:Priming the FileShare send file
Next Topic:extension to EP org.eclipse.ecf.containerFactory
Goto Forum:
  


Current Time: Mon Aug 10 00:02:08 GMT 2020

Powered by FUDForum. Page generated in 0.01826 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top