You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2008/10/09 18:30:44 UTC
[jira] Created: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Improve the TProtocol interface to facilitate more complex protocols
--------------------------------------------------------------------
Key: THRIFT-167
URL: https://issues.apache.org/jira/browse/THRIFT-167
Project: Thrift
Issue Type: Improvement
Reporter: Bryan Duxbury
In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Alexander Shigin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642788#action_12642788 ]
Alexander Shigin commented on THRIFT-167:
-----------------------------------------
Bryan, why do you want to keep something-begin and something-end.
Here is your code:
{code}
public abstract void writeMapBegin(TMap map) throws TException;
+
+ public void writeMapFieldBegin(TField field, TMap map) throws TException {
+ writeFieldBegin(field);
+ writeMapBegin(map);
+ }
public abstract void writeMapEnd() throws TException;
{code}
I think it's much better to make
{code}
public void writeMapField(TField field, TMap map) {
writeFieldBegin(field);
writeMapBegin(map);
writeMapEnd();
}
{code}
I think what sort of changes should be done for every language libs. I've tried implement true/false type for python using current interface, so I can understand your improvement.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639643#action_12639643 ]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
Would love to hear everyone's thoughts on this one. I've done some work on the Compact Protocol, and this patch makes it MUCH simpler.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639487#action_12639487 ]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
The deserialization code doesn't look any different at all. The serialization code might look like:
{code}
writeStringField(new TField(1, TType.STRING), my_str_field);
writeI32Field(new TField(2, TType.I32), my_i32_field);
writeListField(new TList(TType.I32, my_list_field.size()));
for (int i = 0; i < my_list_field.size(); i++) {
writeI32(my_list_field.get(i));
}
{code}
I have a patch I will post later today that's a little more descriptive
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury updated THRIFT-167:
---------------------------------
Attachment: thrift-167.patch
Here's a patch showing the changes I think we should make the the Java TProtocol interface. If this is accepted, we'd probably want to make similar changes to the other libraries. Also, this doesn't include the generator changes that would go along with it.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Chad Walters (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639485#action_12639485 ]
Chad Walters commented on THRIFT-167:
-------------------------------------
I am not sure I understand how this actually plays out. Can you provide a code snippet showing what the generated deserialization might look like for a simple structure?
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642831#action_12642831 ]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
We still need end methods. This is because the structure doing the serialization runs the serialization, not the protocol. If the protocol was in charge, then this would make sense. It'd also make sense if we made Thrift-specific collection subclasses that knew how to serialize themselves.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641056#action_12641056 ]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
Has anyone had a chance to look at these changes?
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641165#action_12641165 ]
David Reiss commented on THRIFT-167:
------------------------------------
My gut instinct is that this will actually create more work than it saves. We will have to retool all of the generators to to use this style. With a stateful protocol, you can just store the TField in an instance variable and then just check that when you get the value (and reset the TField to null).
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury resolved THRIFT-167.
----------------------------------
Resolution: Won't Fix
I've figured out how to avoid needing this change.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (THRIFT-167) Improve the TProtocol interface to
facilitate more complex protocols
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641432#action_12641432 ]
Bryan Duxbury commented on THRIFT-167:
--------------------------------------
Changing the generators for this is trivial. It's replacing two generated method calls with one in the vast majority of cases. Plus, even if the protocol can be stateful to reach the same effect, it will be much more difficult to understand, which will hamper implementations in other languages.
> Improve the TProtocol interface to facilitate more complex protocols
> --------------------------------------------------------------------
>
> Key: THRIFT-167
> URL: https://issues.apache.org/jira/browse/THRIFT-167
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Attachments: thrift-167.patch
>
>
> In doing some exploratory coding on THRIFT-110, it's clear that some improvements to the TProtocol interface would make things much easier.
> What I'm thinking is that we should add a new set of methods that take the TField and value simultaneously. For instance, we'd have writeString(str) and writeStringField(field, str). This way, the protocol would know explicitly that it can write the field id, type header, and value all at once. The exsiting overload (writeString(str)) would still be used when writing containers' contents.
> Existing protocols can implement this behavior very simply as a call to writeField then writeString, so we wouldn't have to do a ton of work to recode them completely. Code generators would have to change to take full advantage of this new interface, but existing generated code would still work, since we'd retain all the original methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.