[ome-devel] Do OME and OME::Remote deal properly with 64-bit OMEIS IDs?

[Zachary Pincus]

Hello all,

I'm trying to figure out a few things regarding OME, OME::Remote, and 
the fact that OMEIS PixelsIDs and FileIDs are 64 bit unsigned integers.

First, in the OMEIS documentation we are told that OMEIS will return 
these values as strings of no greater than 21 characters. Why 21 
characters? 20 decimal digits is enough to store 64 bits of information 
(10^20 >> 2^64), so unless we're talking about a base-9 representation 
of the OMEIS ID values, I'm slightly confused. But this doesn't really 
matter.

My more substantive question concerns the fact that the XML-RPC spec ( 
http://www.xmlrpc.com/spec ) only supports the direct transfer of 
signed 32-bit integers -- anything larger than that must be either 
base64 encoded, or encoded in a different string representation (e.g. a 
string containing the digits 0-9 for "base10 encoding"). However, 
OME::Remote simply passes these values (stored in the database in 
bigint columns) across the wire as XML-RPC integers.

Anyhow, is this behavior a bug? If so, how deep does it go? Presumably 
the perl code itself is savvy to bigint values in the database -- it 
would be no good for large OMEIS ID values to get silently converted to 
floats on platforms where the the native integer is 32 bits.

So, I assume that there's some bigint support in the perl-postgres 
layer? (OME doesn't seem to be using Math::BigInt or its ilk 
directly...) Can this be tapped into to make OME::Remote pass values 
from bigint-typed database columns as strings?

By the way, fixing OME::Remote so that bigint values are always passed 
as base-10 strings would not break the Java XML-RPC client library. 
That code already encodes 64-bit Longs into strings before sending them 
down the wire, and knows how to unpack them from strings if need be.

Thanks,

Zach Pincus

Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine