Python marshal format supports everything we need and is easy to implement in Java. It is roughly equivalent to JSON, but binary.
http://docs.python.org/library/marshal.html wunder On 10/16/08 8:16 AM, "Shalin Shekhar Mangar" <[EMAIL PROTECTED]> wrote: > Hi Todd, > > AFAIK, protocol buffers cannot be used for Solr because it is unable to > support the NamedList structure that all Solr components use. > > The binary protocol (NamedListCodec) that SolrJ uses to communicate with > Solr server is extremely optimized for our response format. However it is > Java only. > > There are other projects such as Apache Thrift ( > http://incubator.apache.org/thrift/) and Etch (both in incubation) which can > be looked at. There are a few issues in Thrift which may help us in the > future: > > https://issues.apache.org/jira/browse/THRIFT-110 > https://issues.apache.org/jira/browse/THRIFT-122 > > On Thu, Oct 16, 2008 at 12:18 AM, Feak, Todd <[EMAIL PROTECTED]>wrote: > >> Reposting, as I inadvertently thread hijacked on the first one. My bad. >> >> Hi all, >> >> I have a handful of custom classes that we've created for our purposes >> here. I'd like to share them if you think they have value for the rest >> of the community, but I wanted to check here before creating JIRA >> tickets and patches. >> >> Here's what I have: >> >> 1. DoubleMetaphoneFilter and Factory. This replaces usage of the >> PhoneticFilter and Factory allowing access to set maxCodeLength() on the >> DoubleMetaphone encoder and access to the "alternate" encodings that the >> encoder provides for some words. >> >> 2. JapaneseHalfWidthFilter and Factory. Some Japanese characters (and >> Latin alphabet) exist in both a FullWidth and HalfWidth form. This >> filter normalizes by switching to the FullWidth form for all the >> characters. I have seen at least one JIRA ticket about this issue. This >> implementation doesn't rely on Java 1.6. >> >> 3. JapaneseHiraganaFilter and Factory. Japanese Hiragana can be >> translated to Katakana. This filter normalizes to Katakana so that data >> and queries can come in either way and get hits. >> >> >> Also, I have been requested to create a prototype that you may be >> interested in. I'm to construct a QueryResponseWriter that returns >> documents using Google's Protocol Buffers. This would rely on an >> existing patch that exposes the OutputStream, but I would like to start >> the work soon. Are there license concerns that would block sharing this >> with you? Is there any interest in this? >> >> Thanks for your consideration, >> Todd Feak >> > >
