Home » Archived » Eclipse Communications Framework (ECF) » Receiving a file with FileShare
|
| Re: Receiving a file with FileShare [message #606369 is a reply to message #606365] |
Tue, 25 July 2006 19:00   |
 Scott Lewis
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 |
Jaap Reitsma
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 #607469 is a reply to message #607465] |
Wed, 26 July 2006 05:08 |
Scott Lewis
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 |
Jaap Reitsma
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 |
Scott Lewis
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
>
|
|
|
| |
  |
Goto Forum:
Current Time: Tue Apr 23 14:58:22 GMT 2024
Powered by FUDForum. Page generated in 0.03324 seconds |
] 
Search
Help
Register
Login
Home
