8 Aug
2012
8 Aug
'12
4:52 a.m.
On 08/07/2012 03:44 PM, Sergiu Dumitriu wrote:
On 08/07/2012 03:43 PM, Denis Gervalle wrote:
Actually, one thing I don't like is that the API is getting even bigger,
with lots of different ways of doing the same thing. Ideally, there
should be only one way of providing the content, and only one way of
retrieving it. And IMO working with byte streams is the right way, and I
think that the current setContent(InputStream) method is the one that's
best.
Returning an OutputStream where the caller can write the content is
opening the door to lots of potential problems. Providing such a method
becomes API, and APIs should be well designed. And an OutputStream in my
head means some implicit constraints that must be well documented:
- should the stream be closed at the end?
- must the response be written before a transaction ends?
- what if nothing is written in the stream, does that mean that the old
content is preserved, or that the attachment is going to be truncated?
Basically, this is a _push_ API, and I for one prefer _pull_ APIs, since
the backend will get the data when it needs it, it doesn't have to
document how long it's going to wait for something to be pushed.
I agree that our current way of dealing with Hibernate is not right. We
should use proper blob streams for big data, like attachment content.
And Hibernate's LobCreator expects a Blob object that offers access to
its content via an InputStream that can be read. Again, Hibernate
expects an input stream from which it will read when it needs to, it
doesn't allow you to write the content into an OutputStream when you want.
So, consider this a -1 until you can convince me that it's indeed
something we want to include in our APIs.
From the current interface, I would use
getContentOutputStream(), since
this would be the opposite of getContentInputStream(). This seems to me
very descriptive compare to a setContent() returning an OutputStream,
since
a set is not supposed to return anything. I would use
setContent(OutputStream) if it was your goal, but this probably not what
you expect.
So, +1 for getContentOutputStream()
+1 as well. > +0 for getOutputStream()
> -0 for other previous proposals.
>
> On Tue, Aug 7, 2012 at 9:01 PM, Caleb James DeLisle <
> calebdelisle(a)lavabit.com> wrote:
>
>> getOutputStream() is not very descriptive although I suppose a good
>> javadoc comment would alleviate
>> the issue, I wrestled with the name myself and settled on setContent()
>> because it overloads the existing setContent() so it should be a bit
>> easier to remember.
>>
>> If you guys like getOutputStream(), I'm happy enough with it.
>>
>> Caleb
>>
>>
>> On 08/07/2012 03:24 AM, Thomas Mortagne wrote:
>>> +1 for the idea in general but same comment than Marius
>>>
>>> On Tue, Aug 7, 2012 at 7:35 AM, Marius Dumitru Florea
>>> <mariusdumitru.florea(a)xwiki.com> wrote:
>>>> I understand the need and I'm +1 but I don't like the method
name
>>>> (neither setContent() nor addContent()). WDYT about getOutputStream()
>>>> ?
>>>>
>>>> Thanks,
>>>> Marius
>>>>
>>>> On Tue, Aug 7, 2012 at 12:06 AM, Caleb James DeLisle
>>>> <calebdelisle(a)lavabit.com> wrote:
>>>>> Hi,
>>>>> In the development of Cassandra attachments, I found I want to
>>>>> load an
>> attachment one chunk at a time and
>>>>> write that chunk to a provided OutputStream, this is how I envision
>> next generation Hibernate attachments working too.
>>>>>
>>>>> I would like to add to XWikiAttachmentContent:
>>>>>
>>>>> public OutputStream addContent();
>>>>>
>>>>> which returns an OutputStream that allows writing the attachment
>> content and upon close,
>>>>> sets the attachment content as dirty and resets the size field.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Caleb
--
Sergiu Dumitriu
http://purl.org/net/sergiu/