[gstreamer-bugs] [Bug 590669] [API] need GstByteWriter or GstChunkWriter

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=590669
  GStreamer | gstreamer (core) | git

--- Comment #3 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2009-10-03 12:24:36 UTC ---
Nice, thanks for implementing this.

Random unconsidered comments/questions:

 - would it make sense for GstByteWriter to derive from GstByteReader, so that
writers can also go back and read things, or is that not really needed?

 - would be nice to allow for the byte writer structure to be stack allocated
as well

 - would be nice to allow for a fixed-size mode where the caller passes in a
chunk of pre-allocated memory; the byte writer wouldn't be able to grow then of
course, but since the functions already return TRUE/FALSE anyway, that should
be easy to add

 - would it be more efficient to maintain current/end pointers so that you
don't have to do start+current_pos for each write? (Does it matter? Do we care?
Was just wondering the same thing about the byte reader the other day)

 - one could merge gst_byte_writer_take_data() and gst_byte_writer_free()
g_string_free()-style (ie. with a do_free boolean and a return value). Not sure
if it's prettier or more desirable, just mentioning it for completeness. It
takes care of the fact that the byte writer will be unusable (or empty again)
after using _take_data(), so avoids misunderstandings (Arguably, that should be
kind of obvious though, so isn't really an issue)

 - _to_buffer() should be renamed/changed so that it's clearer what happens
with the byte writer data IMHO. Maybe it should be _take_data_as_buffer()?
(Unless we decide to go for byte_writer_free(),
byte_writer_free_and_take_data(), and _free_and_take_buffer() or so).

 - how do we best use this when writing something like ASF or quicktime headers
or RIFF chunks (or even the binary registry)? Ie. where we want to write chunks
and nest them. Rely on higher API that then uses GstByteWriter? Or would it
make sense to embed this somehow? (Not sure how or what would be needed, mabe a
parent_chunk pointer or some such, and a hook to update the parent_chunk when a
child chunk is finalised). So I guess the question is if we want to cater for
this: if we do, then another layer of indirection might be needed (so that e.g.
instead of growing the current writer you in fact grow and write to the memory
allocation of the parent_chunk or somesuch).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.