[Webkit-unassigned] [Bug 115364] [SOUP] Move default buffer handling from ResourceHandleClient to ResourceHandleSoup

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=115364





--- Comment #6 from Martin Robinson <mrobinson at webkit.org>  2013-04-30 09:09:34 PST ---
(In reply to comment #5)

> > Likewise, I don't get the final else case. If d->m_readBuffer is allocated at all, shouldn't d->m_readBufferPtr point to it anyway -- since when you get a valid return value from getOrCreateReadBuffer you reset m_readBuffer and m_readBufferPtr.
> 
> That's for redirections, in case of redirection the current soup request is cleaned up (and Ptr is set to 0) and a new one is started for the new request, but we still want to reuse the buffer instead of free/alloc.

Ah, interesting. You need to set m_readBufferPtr to null in order to trigger the creation of a new client buffer. Tricky.

> > Even in that case, the internal buffer (m_readBuffer) is always the same size.
> 
> That's true, we could just check if the m_buffer is NULL or not like the current code does, instead of checking the size. I added the size check in case the size could change in the future, but maybe it's confusing, so I can change it to check the default buffer pointer instead.

I think a NULL check would be a bit clearer, since the size applies to both the embedded/default buffer and the one from the client.

> I don't really mind to change the name, but the method, creates a buffer or returns an existing one, it's pretty clear to me. Regarding the variable name, embedded sounds confusing to me. What bout m_readBufferPtr and m_defaultReadBuffer?

m_defaultReadBuffer, m_internalReadBuffer, m_embeddedReadBuffer all sound good to me. Just so there's a distinction somehow. Thanks.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.