Hey David - I don't think it's been explored in great detail anywhere yet, but my idea was that we'd introduce a layer of abstraction between struct and protocol called serializer. This new object would basically take the guts of the write() and read() methods and move them into a separate class, which the compiler would generate for each struct.
The first draft of this would just be an exercise in refactoring, but once the code was generated in a different class, we could extend he model to generate different kinds of serializers that work better with different protocols. For instance, I could imagine a "CompactSerializer" that meant we didn't have to keep a stateful Protocol, or a JsonSerializer that just made JSON without all the existing machinations. I wish I had more to offer here, but I just haven't had the time to experiment. If you're starting from scratch on a new language implementation, I'd recommend just porting the Java library as directly as you can manage. It's extremely mature and robust - and it has pretty decent tests. Let me know if you run into specific roadblocks. I'm always happy to help new languages come on board! -Bryan On Fri, Apr 29, 2011 at 4:36 PM, David Nadlinger <[email protected]>wrote: > Hello list, > > as this is my first post here, let my quickly introduce myself first: My > name is David Nadlinger, I'm a student from Austria, and I am going to work > on a Thrift-related project during this year's Google Summer of Code under > the umbrella of Digital Mars: a Thrift implementation for/in the D > programming language. [1] > > While preparing my project proposal, I came across a JIRA entry which > discusses the idea of pluggable serializers [2], and as I will implement a > new language library during the course of the project, this obviously caught > my attention. As I am somewhat familiar with the way serialization is > currently implemented, I can see the limitations of the existing approach, > but are there any details on how exactly the design of the proposed new > solution would look like? Maybe there is some previous discussion on the > topic I missed while looking through the mailing list archives? Otherwise, > Bryan, would you mind quickly sketching how you envision the design? > > As I am currently thinking about the library design for D, I would be > grateful for any feedback, also regarding any other lessons learned about > the current C++/Java library design. > > Thanks a lot, > David > > > [1] http://klickverbot.at/code/gsoc/thrift/ (nothing of interest there > yet) > > [2] https://issues.apache.org/jira/browse/THRIFT-769 >
