From dev-return-37471-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Mar 01 21:51:41 2011 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 34179 invoked from network); 1 Mar 2011 21:51:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Mar 2011 21:51:40 -0000 Received: (qmail 84759 invoked by uid 500); 1 Mar 2011 21:51:40 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 84552 invoked by uid 500); 1 Mar 2011 21:51:39 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 84536 invoked by uid 99); 1 Mar 2011 21:51:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Mar 2011 21:51:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 209.85.214.50 as permitted sender) Received: from [209.85.214.50] (HELO mail-bw0-f50.google.com) (209.85.214.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Mar 2011 21:51:33 +0000 Received: by bwz2 with SMTP id 2so7624563bwz.37 for ; Tue, 01 Mar 2011 13:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qn9Oebwu3xhlF6oKqkwwjuFKXdaP3fn7L/Kuhb3IonA=; b=IUUq3doogTbLo/LCyiqkt4E3WStejFgIz7NxYeKraqk78KQ27vxTJHJQEoc3XTVCQM sQ32VMSW4YSSi7+vac7Omexzbqqv/2Z9zJYQBdbqEAMqAO4sfiXajRoA3G8wqdOiueVQ izNsOYRzPMYG2O01/zma6mbERFqh7BpcJVFSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WCldjpxPWDxaCiwUtbOPnlt950xXvsaKq7DAk/74yEciJYlEORzaRBGspVgcHLn2az P70DRilhVPevuMnD8yHWdUUxkG4JtI880GkKpMa7lXrKBRyl2iRcyffPYtcnsH7IGW4a UM/r27mh7jPV51F7VWB0/fqNUD8B8uWncQvR0= Received: by 10.204.71.77 with SMTP id g13mr6664251bkj.170.1299016271733; Tue, 01 Mar 2011 13:51:11 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (ver78-3-89-80-150-189.dsl.club-internet.fr [89.80.150.189]) by mx.google.com with ESMTPS id a17sm3700854bku.23.2011.03.01.13.51.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2011 13:51:10 -0800 (PST) Message-ID: <4D6D6A4C.7080007@gmail.com> Date: Tue, 01 Mar 2011 22:51:08 +0100 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: Serializers References: <4D6D1791.6040009@gmail.com> In-Reply-To: <4D6D1791.6040009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I was a bit optimistic saying that we should merge the serializers with the classes that are operating on : the problem is that if we do that, we will have to call methods like : DefaultEntryAttribute.serialize() Not very convenient. I think it's probably better to have an EntryAtrributeSerializer helper class instead of static methods in classes. As a matter of fact, for Entry, we may have bigger trouble : should the methods be injected into DefaultEntry ? Or ClonedServerEntry ? Or ImmutableEntry ? Or ClonedServerEntrySearch ? ... See what I mean, I guess. On 3/1/11 4:58 PM, Emmanuel Lecharny wrote: > Hi guys, > > Last week, I started to rewrite the serializers, creating some > dedicated classes for each element needing to be serialized. > > Each class contains a serialize()/deserialize() method. > > I'm now wondering if it wound't be better to simply move those static > classes into the main classes being serialized/deserialized. Alex does > think so, and I'm on line whith his option. > > The reason why I created an additional class was to avoid modifying > the main classes. Also not that the class implementing Externalizable > will call those dedicated methods. > > Thoughts ? > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com