Some observation 1. the sandbox folder has whole of MINA code. Will be great if we can remove other files
AFAIK, protocol buffer codec is a binary data binding framework, something similar to XML-Data binding framework's like JAXB, Castor, XMLBeans. Google's implementation reminds of CORBA IDL's There is basic operational similarity of Google Protocol Buffer codec with prefixed string decoder. We have a length and then actual messages. It will be worthwhile to explore if we can align the google codec with prefixed string codec. There is one more situation that must be though about is piggybacked messages. the implementation can receive a packet with one message ending and another message starting (again by nature of TCP). So returning true from decoder may result in an exception (more data remaining) [Please correct me if I am wrong] Also, is it worthwhile to have a mechanism to add extensions into ExtensionRegistry? or the library is doing it. Would like to spend some more time with the code before commenting more on this. Though it will be worthwhile to have this codec with us. Once we review the code, lets vote for the same. Shall try to run this implementation and validate it against my possible use case. Though would have loved to have an implementation where I don't have to define .proto files. (I know the implementation doesn't work that ways) ashish On Thu, Jan 8, 2009 at 2:50 AM, Emmanuel Lecharny <[email protected]> wrote: > Hi guys, > > a couple of weeks ago, Thomasz Blachowicz submitted a patch including some > Google protocol buffer codec (see > https://issues.apache.org/jira/browse/DIRMINA-654). > > I just injected it into the sandbox, for us to review the code : > http://svn.apache.org/viewvc?rev=732497&view=rev > > If some of us can review the code and tell if it's ok, we then would be able > to inject it in the project (maybe after 2.0, depends). > > Or if you have any suggestion, or think that it's not worth being a part of > MINA, feel free to give some feedback.
