From mime4j-dev-return-888-apmail-james-mime4j-dev-archive=james.apache.org@james.apache.org Fri Jan 08 17:01:59 2010 Return-Path: Delivered-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Received: (qmail 23322 invoked from network); 8 Jan 2010 17:01:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Jan 2010 17:01:58 -0000 Received: (qmail 85637 invoked by uid 500); 8 Jan 2010 17:01:58 -0000 Delivered-To: apmail-james-mime4j-dev-archive@james.apache.org Received: (qmail 85602 invoked by uid 500); 8 Jan 2010 17:01:58 -0000 Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mime4j-dev@james.apache.org Delivered-To: mailing list mime4j-dev@james.apache.org Received: (qmail 85592 invoked by uid 99); 8 Jan 2010 17:01:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 17:01:58 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of apache@bago.org designates 209.85.218.217 as permitted sender) Received: from [209.85.218.217] (HELO mail-bw0-f217.google.com) (209.85.218.217) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jan 2010 17:01:50 +0000 Received: by bwz9 with SMTP id 9so11727799bwz.12 for ; Fri, 08 Jan 2010 09:01:27 -0800 (PST) Received: by 10.204.9.4 with SMTP id j4mr453273bkj.160.1262970087709; Fri, 08 Jan 2010 09:01:27 -0800 (PST) Received: from mail-fx0-f212.google.com (mail-fx0-f212.google.com [209.85.220.212]) by mx.google.com with ESMTPS id 16sm7770305bwz.11.2010.01.08.09.01.26 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jan 2010 09:01:27 -0800 (PST) Received: by fxm4 with SMTP id 4so16302135fxm.12 for ; Fri, 08 Jan 2010 09:01:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.87.197 with SMTP id y47mr1502152wee.202.1262970086413; Fri, 08 Jan 2010 09:01:26 -0800 (PST) X-Originating-IP: [78.134.13.238] In-Reply-To: <1262968925.12096.14.camel@ubuntu> References: <9426afb71001051133g3f4a065bsb7058cc6e2ce09dd@mail.gmail.com> <1262871132.5718.21.camel@ubuntu> <9426afb71001070554v2d19c0b0he0dc3971fb306c1a@mail.gmail.com> <1262873631.5718.28.camel@ubuntu> <9426afb71001070632ia5dcdd7idf0fcd75a07f475e@mail.gmail.com> <1262878002.5718.40.camel@ubuntu> <9426afb71001070745l2ad36796vc6efdbe70adbaa4d@mail.gmail.com> <1262944734.12096.4.camel@ubuntu> <9426afb71001080219y2a111209rfcca2978606dc973@mail.gmail.com> <1262968925.12096.14.camel@ubuntu> Date: Fri, 8 Jan 2010 18:01:26 +0100 Message-ID: <9426afb71001080901s25f7f380sfd7c86db9248818a@mail.gmail.com> Subject: Re: [cycleclean] minor naming tweaks; was Re: [cycleclean] branch review and questions From: Stefano Bagnara To: mime4j-dev Content-Type: text/plain; charset=ISO-8859-1 2010/1/8 Oleg Kalnichevski : > With so many classes moved to different packages an iterative merge > would just be too hard. I am +1 to merging the entire branch down to > trunk. Remaining issues can be dealt with once the branch has been > merged. > > Minor stuff: > > (1) I also would like to propose a few minor changes / renames. Ideally, > I would like the 'steam' package to be fully usable out of the box. So, > it would be good if DefaultBodyDescriptor was moved to 'steam' and > renamed to BasicBodyDescriptor for consistency. I also think > FullBodyDescriptor is a better name for MaximalBodyDescriptor DefaultBodyDescriptor would reintroduce the field parsing dependency to the stream package. So, unless we say that we don't care about separation between stream parser and field parsing, there is no way to use stream alone. Currently the BodyDescriptor interface is the "service" that let the "stream" parser to describe the body without having any knowledge about what fields describe them and how they are parsed. Not sure this is the best solution we can find, but this is how it currently works and how it currently allow us to keep separation between the 2 packages. About Maximal and Default BodyDescriptors I didn't studied the details, but currently my opinion is that we don't need 2 of them. MaximalBodyDescriptor is already lazy parsing additional fields, so even if you just need the defaultbodydescriptor stuff performances would not be hit by using the Maximal. > (2) I have a number of test cases failing on me when run on Windows. I > think mismatch in line delimiters is the cause. I would be great to have > this fixed before the merge. All test cases used to work on Windows. I'm on windows too :-( ... I remember I worked around this issue in older mime4j versions, too... I'll have a look at it. > (3) Tons of javadocs need to be reviewed / updated. I am willing to > help. Whenever I move some stuff around the javadocs are not always correctly updated, so I just wanted to collect more thoughts about the merging and then deal with this details. Thank you for reviewing, and let me know if you prefer the older packaging or the newer one (cycleclean vs cycleclean-pre-packagerenames) Stefano