Archived

This forum has been archived. Please start a new discussion on GitHub.

More Question on file trans

alexm
alexm
in Help Center
I used the followin Slice:
FTP{
sequence<byte> ByteSeq;
interface FileStore
{
ByteSeq get(string name);
void put(string name, ByteSeq s);
};
}

when I call get from remote, How ever I try I could not the bytes returned as expected, here are snippet example How I call it and did it.

class FileStoreI( FTP.FileStore):
def get ( self, name, current=None):
fh = open( ...)
buf = fh.readlines( )
return buf

buffer = proxy.get( "/download/eclipse.zip", current.ctx)

I get on the client exceptions.ValueError, and same on server too.

My question is how do I get ByteSeq returned to me, and in what form should I expect it. I look the many example they are either to simplistic or way over my current understanding of ICE.

Comments

  • mes
    mes California
    Hi,

    The ValueError occurs because readlines() returns an array of strings, which is not compatible with a Slice sequence<byte>. You could change your Slice definitions to use a sequence<string> instead, which is probably the quickest way to proceed.

    Good luck,
    - Mark
  • alexm
    alexm
    My Intent was to transfer the content of the file in binary mode. I tried this in C++ and java did not have problem, only in python, is there a special preprocessing/converting I must do to the read value befor I returned like:
    buffer = fd.readline( ...)
    return ToBin( buffer)
  • mes
    mes California
    Hi,

    It looks like there is no easy way to convert a string into a Python tuple or list of bytes, which is what Ice currently requires as the value for sequence<byte>. Unfortunately, I think you'll need to convert the strings into tuples yourself.

    We'll look into changing Ice for Python so that a string can be used where a sequence<byte> is expected.

    Take care,
    - Mark
  • alexm
    alexm
    Using base64 module does seems to work, let me do more testing, if it passes I will post my solution.
  • hiasl
    hiasl
    Hi Mark,

    did you already make the changes for Python? Since i need to transfer binary files too, i would appreciate this feature very much :) At this moment i convert all data (strings and binaries) to hexstrings which works, but forces the servant and the client to manipulate data.

    Bye,
    Matthias
  • lievenmatthys
    lievenmatthys
    Hello,

    I decided to give Ice a try after seeing CORBA stall for some time now, and noticing the support for small devices.

    I'm also using Python, and I ran into the problem of transferring large binary buffers.
    Currently the slice type byte is mapped to Python type int.

    I would dare to argue that in Python, the raw byte type is rather a char than an int.
    Byte buffers in Python are represented by strings (a Python string can contain 0x00), strings being defined as a kind of packed lists of chars.

    Python strings follow the same semantics as lists and tuples for slicing, concatenating etc.
    This choice also shows in Python's file interface, where there is in fact little or no distinction between writing a string, or writing a buffer.
    Also, Python has strong support for constructing (packing) and interpreting (unpacking) strings (buffers) via the module 'struct'.
    This decision does mean that in order to calculate with byte values, you need to convert them to int through the ord() function. However, this is not a big issue. The struct module avoid most of these direct calculations anyway, in an elegant way.

    The big disavantage of the current sequence<byte> mapping is that you end up with a times-four memory usage upon reception of the value, and in 95% of the cases you need to use CPU time to convert to a string with :
    "".join(map(chr,myReceivedByteSeq))
    because you want to just dump it into a file, display it on the screen as an image, interpret it with functions of the struct module...
    Similarly, at the sending side you need to convert the buffer you got from a file or a socket by wrapping it :
    map(ord, buffer)
    to get a sequence of ints, which is probably less overhead.

    Hence, my argument is: in Python, binary buffers are by convention represented by strings, as you can see in many APIs.
    I would suggest to at least provide an alternative language mapping for byte and sequence<byte>, using Python strings.

    kind regards,
    Lieven
  • mes
    mes California
    Welcome to the forum!

    Please update your signature as described in this post.

    The next major release of Ice (i.e., version 3.2) will most likely use a string as the default mapping for sequence<byte>, with optional metadata to use a tuple or list instead.

    Take care,
    - Mark
  • lievenmatthys
    lievenmatthys
    Sounds good !

    fyi, I'm running parts of a home automation project on CORBA (evolved from C/orbit and VB/vborb to Python/Fnorb, C++/TAO and Java/jdk orb)

    It would be cool to include GSMs and PDAs, so I'm trying out Ice now.
    I had noticed Ice a few years back already, however.

    Thanks,
    Lieven

Categories