On Sun, May 2, 2010 at 10:28 PM, <ma...@bestweb.net> wrote:
> On the wire, Thrift is permissive enough to send a value of the type
> LIST 2 STRUCT 1 I16 2 I32 STOP 1 DOUBLE 5 STRING STOP
> or
> list { struct {1: I16, 2:I32}, struct{ 1:double, 5:string}}
> In that sense, it will support list<any>.
>
> However, in a typed language (and probably in any language other than one
> with duck-typing), it will be difficult (or impossible) to convert the
> received object into an acceptable object.
>
Hmmm... why do you think so? It's usually pretty trivial (though not always
pretty) to do these types of raw-data to typed-objects conversions.
[[ This also suggests that there is a possible compression available here:
> specify complete types as arguments to containers, as opposed to repeating
> them for each element. Taken to its conclusion, however, this requires
> sending the type signature in advance of the actual message, as opposed to
> interleaved with it.
>
If the collections are homogeneous, yes. If not, then the current encoding
is just fine. I'd argue that the current encoding is just fine since I
need support for heterogeneous collections ;)
Note that, with that one exception, it seems unclear where you could save
> logical space in the type-encoding overhead, and still retain the ability
> to change the number of fields & their types and then detect that there is
> an incompatiblity.
>
> You may, of course, be able to compress the logical type information, as
> well as the values transmitted.]]
>
> So, the problem with list<any> is not necessarily the wire encoding, but
> specifying the expected type -- what should the demarshaller turn it into?
>
A generic list (or more generally, a generic collection/container). As far
as I know, all languages supported by Thrift also support generic +
heterogeneous collections.
alex
