[Vortex] Feature Suggestion

[Yourch, Chris]

Hooray!  The callback solution seems like a good one and maybe someone
can build a base VortexStream object on top of it?  

Personally, I like the abstraction and power that a stream object
provides. For example, you could derive from the base VortexStream to
create a VortexFileStream that handles the details of marshalling a
file, its attributes, timestamps, named streams, ACL's, etc, from one
end of the wire to the other.


-----Original Message-----
From: vortex-bounces at lists.aspl.es [mailto:vortex-bounces at lists.aspl.es]
On Behalf Of Francis Brosnan Blazquez
Sent: Friday, August 24, 2007 6:55 AM
To: Sam Roberts
Cc: vortex at lists.aspl.es
Subject: Re: [Vortex] Feature Suggestion

Hi Sam,

> I'm not sure its so simple. Vortex can only send a message that is in
> memory (const char*, size_t), though BEEP contains the ability to send
> a
> message as a series of frames, which is useful for large messages.

Ok,..

> If I defined a simple profile where the MSG data was the file, and a
> RPY
> or an ERR indicated successful/unsucessful upload, how would I send
> that
> MSG if the file was larger than available memory?

...see next.

> Through VortexOnFrameReceived() there is good receiving-side support
> for
> streamed/large messages, but there doesn't seem to be the same level
> of
> support on the sending side.

I agree with you Sam with some exceptions ;-)

To send a file or a big message involves several protocol decisions that
must be addressed by the application level on top of Vortex Library,
that is, by a profile.

Thinking about this problem it is clear it could be added some support
to provide some callbacks to send a message, which are called to pull
data from. This sounds good to me [1].

This will solve the need to open the file and transport all its content
to a single huge message inside memory. Now the vortex engine will call
to those handlers to gather data to be sent etc, but...

...at the listener side it is assumed you have installed a custom
profile that must be minimally configured to make the previous transfer
to happen. 

It comes to my mind that profile should configure the frame received to
avoid vortex to concat fragmented frames, file handle to be used, the
location of the file, permissions and file attributes..

At the end as you see, providing a facility to send a file this way will
only solve the following pseudo code at the client side:

  while (not end of file) {
      read 4k from the file
      send the message
  } 

...which I think it is not the heart of the problem.

Cheers!

PS: I've opened a bug report to complete this feature [1].

[1] http://dolphin.aspl.es/cgi-bin/bugzilla/show_bug.cgi?id=327

> Cheers,
> Sam 
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.


_______________________________________________
Vortex mailing list
Vortex at lists.aspl.es
http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex