Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop, mail # general - [VOTE] Direction for Hadoop development


+
Owen OMalley 2010-11-29, 22:30
+
Doug Cutting 2010-11-29, 23:14
+
Owen OMalley 2010-11-30, 00:22
+
Doug Cutting 2010-12-01, 15:21
+
Owen OMalley 2010-12-01, 15:40
+
Doug Cutting 2010-12-06, 19:30
+
Chris Douglas 2010-12-06, 22:40
+
Doug Cutting 2010-12-06, 23:45
+
Roy T. Fielding 2010-12-07, 01:09
+
Arun C Murthy 2010-12-07, 16:45
+
Doug Cutting 2010-12-07, 17:18
+
Roy T. Fielding 2010-12-07, 22:37
+
Doug Cutting 2010-12-08, 18:12
+
Owen OMalley 2010-12-14, 03:08
+
Eric Sammer 2010-12-14, 04:49
+
Owen OMalley 2010-12-14, 05:43
+
Eric Sammer 2010-12-14, 07:14
+
Owen OMalley 2010-12-14, 19:08
+
Jay Booth 2010-12-01, 16:29
+
Scott Carey 2010-12-08, 03:33
+
Konstantin Shvachko 2010-12-01, 01:57
+
Owen OMalley 2010-12-01, 19:11
+
Owen OMalley 2010-12-06, 17:16
+
Chris Douglas 2010-12-06, 18:40
+
Arun C Murthy 2010-12-06, 18:46
+
Tom White 2010-12-06, 21:14
+
Konstantin Shvachko 2010-12-07, 11:27
+
Doug Cutting 2010-12-07, 17:22
+
Konstantin Shvachko 2010-12-07, 18:26
Copy link to this message
-
Re: [VOTE] Direction for Hadoop development
Doug Cutting 2010-12-08, 18:55
On 12/07/2010 10:26 AM, Konstantin Shvachko wrote:
>> I no longer think we should add any new serialization implementations to
> the kernel.
>
> Not clear. Do you propose to keep current serialization(s) and not add new
> ones?
> Or do you propose to replace current serialization by abstract interfaces
> and move implementations to libraries?

We can't move existing serialization implementations to an optional
library without breaking compatibility.  Long-term that might be nice,
but I am not proposing that short-term.  Short-term I propose we avoid
adding new serialization implementations to the default classpath,
especially those that add new dependencies to every task.  Long-term we
might split library code into perhaps a few categories:
  - mandatory: this might include, e.g., IdentityMapper and
IdentityReducer, the default implementations.
  - back-compatible: the collection of library components that were
provided on the default classpath and can be enabled for back-compatible
behavior.
  - optional: components that jobs can optionally depend on.  This is
where new components that are not mandatory would be added.

Doug
+
Steve Loughran 2010-12-01, 12:25
+
Eric Sammer 2010-12-07, 03:36
+
Owen OMalley 2010-12-07, 08:13
+
Jeff Hammerbacher 2010-12-07, 10:23
+
Arun C Murthy 2010-12-07, 16:12
+
Doug Cutting 2010-12-07, 17:26
+
Owen OMalley 2010-12-07, 18:25
+
Doug Cutting 2010-12-08, 19:20
+
Eric Sammer 2010-12-07, 18:08
+
Arun C Murthy 2010-12-07, 15:55
+
Jay Booth 2010-12-07, 16:06