hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Douglas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6685) Change the generic serialization framework API to use serialization-specific bytes instead of Map<String,String> for configuration
Date Fri, 19 Nov 2010 19:46:19 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933931#action_12933931
] 

Chris Douglas commented on HADOOP-6685:
---------------------------------------

bq. I had hoped that not threatening a veto but rather providing strong criticism would elicit
compromise and collaboration. It seems to have unfortunately achieved the opposite. I am sorry
to learn that this strategy has failed and, yes, I am now leaning towards a veto of this issue.

What would a compromise solution look like? You've asserted that you preferred the previous,
stringly-typed solution, which is known. But your comments, so far, have not been actionable.
You wrote a missive on the virtues of Avro and standard file formats. When Tom brought it
up, you objected to packaging. Your only consistent theme has been the scope of the patch,
where you vacillate between (0) splitting up work that sprawls across too many domains and
(1) importing large, related issues (project direction, redesigning {{Configuration}}, etc.).
Owen has responded to all of these respectfully, by fully outlining his reasoning, but cannot
respond in code because most of your objections are too general or diffuse to implement. That
is, without adopting the patches you prefer _instead_ of these.

Short of adopting your solution- which was vetoed as unacceptable not only by Owen, but by
others- where are you open to compromise? If the diff were spread around different issues,
would you restrict your veto to a subset of them? Which of your objections do you consider
important enough to block the progress you grudgingly agreed to months/days ago?

I'm +1 on the patch as-is (with the minor caveat that the leftover imports in {{Text}} should
be omitted). I like the direction, the type safety, and its independence of {{Configuration}}.
The way things are configured in Hadoop today is horrific. I think we can do better and the
progress made here should be committed.

> Change the generic serialization framework API to use serialization-specific bytes instead
of Map<String,String> for configuration
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-6685
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6685
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Owen O'Malley
>            Assignee: Owen O'Malley
>             Fix For: 0.22.0
>
>         Attachments: libthrift.jar, serial.patch, serial4.patch, serial6.patch, serial7.patch,
SerializationAtSummit.pdf
>
>
> Currently, the generic serialization framework uses Map<String,String> for the
serialization specific configuration. Since this data is really internal to the specific serialization,
I think we should change it to be an opaque binary blob. This will simplify the interface
for defining specific serializations for different contexts (MAPREDUCE-1462). It will also
move us toward having serialized objects for Mappers, Reducers, etc (MAPREDUCE-1183).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message