Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jasnell@gmail.com designates
 64.233.162.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=h8u3EIC3vStEAQ+hwHIqKkBYXIohN0Uu1pRxlSD5P8GAkB1uDJTRrk53HPh0OPtk4aEehIyCyQLp4Z3YEAzweS6VFHD7mUjS152Opygz9n7dIsvwC92+qjSCNoZO8uibYH2ze7qd+9r0JBNBppubO2MeIqxTkZWPUMlsNItXo4M=
Message-ID: <4730E50E.7050407@gmail.com>
Date: Tue, 06 Nov 2007 14:05:02 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: svn commit: r591523 - in /incubator/abdera/java/trunk:
 core/src/main/java/org/apache/abdera/
 core/src/main/java/org/apache/abdera/parser/
 core/src/main/java/org/apache/abdera/util/
 core/src/main/java/org/apache/abdera/writer/ examples/src/main/ja
References: <29a761a00711031003w11a87f2aw3ac1d058ac23a96c@mail.gmail.com>
 <29a761a00711061228j75e810d0j8caf8b91a932c224@mail.gmail.com>
In-Reply-To: <29a761a00711061228j75e810d0j8caf8b91a932c224@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Right now, the implementation flushes the buffer automatically during
write.  We can have an option to disable autoflushing.  We can leave
reseting the buffer to whatever stream/writer we're writing to.

- James

Brian Moseley wrote:
> On Nov 3, 2007 9:03 AM, Brian Moseley <bcm@osafoundation.org> wrote:
> 
>> *cheer*
>>
>> i had meant to suggest this a while back, but it totally slipped my
>> mind. i'm *very* happy to see it land, because Cosmo can often deliver
>> huge feeds. what features are missing besides xml:lang and xml:base? i
>> might be able to help.
> 
> something that needs to be considered when switching to streamed
> writing - what happens if you write enough data to commit the
> response, and then an error occurs? how does the error get reported to
> the client?
> 
> my first thought is to have the writer buffer each entry and only
> write it out when the close entry method is called. then, at any point
> before the entry is closed, allow the caller to signal an error
> condition. the writer would throw away the buffered partial entry and
> instead write some sort of error element to the stream.
> 
> thoughts?
>