Thing is that I would like to establish a "shared" memory[and/or]storage between java apps and perl for instance. Something like memcached on acid.
Probably the byte[] most of the times need to be some sort of string rep anyway (JSON or Properties file syntax maybe) to make them able to handle the data. /M On Sat, Jun 7, 2008 at 9:12 PM, Bryan Duxbury <[EMAIL PROTECTED]> wrote: > Yeah, don't use base64. There's no point to that if you have a binary data > type available to you. > > Will the clients of this hashmap know the types of the objects they are > retrieving? If so, my original suggestion of using binary types stored and > de/serializing at the application layer probably still applies. > > -Bryan > > > On Jun 7, 2008, at 9:58 AM, Marcus Herou wrote: > > I'm not 100% sure why I switched, was thinking that the clients could send >> Base64 encoded strings back and forths but to be honest that's a little >> lame. >> >> It's 5 mins work to switch back and I will do so... >> >> /M >> >> On Sat, Jun 7, 2008 at 6:52 PM, Johan Stuyts <[EMAIL PROTECTED]> wrote: >> >> The only real constraint currently will be that the client need to >>> >>>> encode/decode objects to a string representation. I initially made the >>>> cache >>>> store byte[] but switched to strings. >>>> >>>> >>> Why did you make the switch? Thrift has a binary type which does what you >>> need and is supported by all language bindings. Using 'binary' should >>> remove >>> the need to encode the data as strings on the client side. >>> >>> -- >>> Kind regards, >>> >>> Johan Stuyts >>> >>> >> >> >> -- >> Marcus Herou CTO and co-founder Tailsweep AB >> +46702561312 >> [EMAIL PROTECTED] >> http://www.tailsweep.com/ >> http://blogg.tailsweep.com/ >> > > -- Marcus Herou CTO and co-founder Tailsweep AB +46702561312 [EMAIL PROTECTED] http://www.tailsweep.com/ http://blogg.tailsweep.com/
