Return-Path: 
 <notifications-return-2336-apmail-accumulo-notifications-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id F3D20E8C6
	for <apmail-accumulo-notifications-archive@minotaur.apache.org>;
 Sun,  3 Feb 2013 21:52:12 +0000 (UTC)
Received: (qmail 2690 invoked by uid 500); 3 Feb 2013 21:52:12 -0000
Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org
Received: (qmail 2663 invoked by uid 500); 3 Feb 2013 21:52:12 -0000
Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:notifications-help@accumulo.apache.org>
List-Unsubscribe: <mailto:notifications-unsubscribe@accumulo.apache.org>
List-Post: <mailto:notifications@accumulo.apache.org>
List-Id: <notifications.accumulo.apache.org>
Reply-To: jira@apache.org
Delivered-To: mailing list notifications@accumulo.apache.org
Received: (qmail 2654 invoked by uid 99); 3 Feb 2013 21:52:12 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Feb 2013 21:52:12 +0000
Date: Sun, 3 Feb 2013 21:52:12 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12629713.1359475720080.236922.1359928332680@arcas>
In-Reply-To: <JIRA.12629713.1359475720080@arcas>
References: <JIRA.12629713.1359475720080@arcas>
Subject: [jira] [Commented] (ACCUMULO-1003) what is the point of
 SecuritySerDe?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/ACCUMULO-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569906#comment-13569906 ] 

Christopher Tubbs commented on ACCUMULO-1003:
---------------------------------------------

This is overly complex, and the generic parameters don't provide compile time checks correctly.

For instance, say I want to serialize a UserPassToken:
{code:java}
UserPassToken token = new UserPassToken("user", "password".getBytes());
token.getSerDe().serialize(token);
{code}

Not only does this fail to compile, without casts that obviate the use of generic parameters, it's confusing to pass token twice.

To support a generic serialization strategy, it would be preferable to have some sort of visitor pattern like:
{code:java}
public class SecurityToken<T extends SecurityToken<T>> {
    public <S> S serialize(Serializer<? extends T,S> serializer);
}
// with a specific implementation like
public class UserPassToken<UserPassToken> {
    public <S> S serialize(Serializer<? extends UserPassToken,S>);
}
// which could be used like
public class UserPassToBytesSerializer extends Serializer<UserPassToken,byte[]> {...};
byte[] bytes = token.serialize(new UserPassToBytesSerializer());
{code}

But even this, while simple and flexible for users, is a bit complex to maintain. I'd prefer just a simple Writable, or other "convertToBytes()" / "convertFromBytes()" simple strategy.
                
> what is the point of SecuritySerDe?
> -----------------------------------
>
>                 Key: ACCUMULO-1003
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1003
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: master, tserver
>            Reporter: Eric Newton
>            Assignee: John Vines
>             Fix For: 1.5.0
>
>
> What is the point of the factory method getSerDe() (which, BTW is an awful name)?   Why not just make SecurityToken Writable?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira