Hi, I just posted this question on stackoverflow, I'd appreciate your
answer...
http://stackoverflow.com/questions/2757040/rpc-for-java-python-with-rest-support-html-monitoring-and-goodies
RPC for java/python with rest support, HTML monitoring and
Generally, we've said that it could be possible, but we haven't made it so
yet.
My personal preference would be not to support this. I understand the need
for heterogeneous collections, but I think that any is a pretty broad
category to allow in a collection and not have to compromise something.
Good to know.
In this case, I'm actually not looking for something optimal in terms of
efficiency. The data structures I'm passing in are small and the services
I'm calling are coarse-grained so the transport+marshalling costs should be
relatively insignificant compared to what happens in the
Alex Boisvert wrote:
In this case, I'm actually not looking for something optimal in terms of
efficiency. The data structures I'm passing in are small and the services
I'm calling are coarse-grained so the transport+marshalling costs should be
relatively insignificant compared to what
2010/5/3 Bjørn Borud bbo...@gmail.com
On Mon, May 3, 2010 at 11:16 AM, Ran Tavory ran...@gmail.com wrote:
So far I've looked at thrift and avro and they are both nice in some
ways,
but don't check all my list.
it might be very useful if you briefly summarized the top N things you feel
In languages other than Java, unions are not implemented - they're just
structs. I'd love for folks to step up and contribute union implementations
in their favorite libraries.
-Bryan
On Mon, May 3, 2010 at 9:22 AM, Mayan Moudgill ma...@bestweb.net wrote:
Yes, you can use unions. This _DOES_
On Mon, May 3, 2010 at 10:03 AM, Mayan Moudgill ma...@bestweb.net wrote:
Apropos the discussion on scalar/string compression in the
https://issues.apache.org/jira/browse/THRIFT-110
I'm curious: if a particular application would tend to compress better
using a different algo than the one(s)
On Mon, May 3, 2010 at 10:03 AM, Mayan Moudgill ma...@bestweb.net wrote:
The idea of marshalling to strings seems somewhat counter-productive; after
all, you're marshalling the data using Thrift, which then gets sent to a
server, and demarshalls it. Now, on top of that you're adding another
thanks folks
On Mon, May 3, 2010 at 8:43 PM, Bryan Duxbury br...@rapleaf.com wrote:
On Mon, May 3, 2010 at 2:16 AM, Ran Tavory ran...@gmail.com wrote:
6. Provides some nice monitoring interfaces such as: JMX, web page
status
reports (e.g. packets in, packets out, error rate etc)
I
This only appears to be in the lib/rb directory, though. I'm not seeing any .o
files in the C++ library or the compiler, for instance.
mcs...@devrs001 /tmp/thrift/thrift-0.3.0 $find . -name *.o
./lib/rb/ext/binary_protocol_accelerated.o
./lib/rb/ext/compact_protocol.o
The ruby stuff also has the annnoying bit where it doesn't use destdir
with 'make install' which pretty much makes it impossible to package
thrift using traditional means. For the RPM and debs I build of thrift
I run with --without-ruby to work around this. It would be awesome if
whoever was the
You might call me the ruby maintainer. However, I don't think I'll be of
much help with this one, since I only use the gem version of the ruby libs.
On Mon, May 3, 2010 at 3:37 PM, Anthony Molinaro
antho...@alumni.caltech.edu wrote:
The ruby stuff also has the annnoying bit where it doesn't
Strong +1. If you want XML, you know where to find it. :)
/r$
--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/
The non-gem version respected DESTDIR if I recall (that was the
mechanism I used to use to package it), but that was tossed when the
gem package (the defacto main distribution) became the only package.
We figured it didn't matter much - the only people not using gems tend
to be people repackaging
If the goal of Thrift was to transport strongly typed data, then it begs
the question: why was the protocol scheme being used currently adopted?
Clearly, if the data is typed with the types being agreed to at both
ends, then NO type information needs to be exchanged (other than you
The protocol scheme was written the way it was because it was very simple,
transparent, straightforward to implement, safe to version changes, and
reasonably defensive.
- Field identifiers are necessary for versioning
- Type identifiers are necessary so that we know how to skip fields that we
I wouldn't have worried too much about the encoding; you can do it using
pretty much the same write*() interface with the following caveats:
- all writes are to an array (generally, I prefer a 2D array of arrays)
- writeFieldBegin pushes the offset within the array and advances by 4 bytes
-
17 matches
Mail list logo
