Re: Serialization in libgobject

[Tim Janik <timj imendio com>]

On Thu, 25 May 2006, Stefan Kost wrote:

> Hi Tim,
>
> thanks for the extensive comments and detailed concerns. Don't you think
> it would be good to keep the buzzgilla issue open. Its an enhancement
> request after all and there seems to be several people wanting to have
> it.

well, my concern is that most of them want/think different things about
serialization which was the main point of my last email.

i.e. if you want to cover beast's serialization need, you already need
2 different serializers. if you then also want to cover GStreamer needs,
and maybe properly human digestible config files, you can easily end
up with 3 or 4 sets of mutually exclusive requirements.

so without precise definition of the usage cases:
- the exact required behaviour of a GLib serializer isn't clear;
- we'll end up with lots of projects still rolling their own serializer
  because the glib one doesn't cover their needs;
- the serializer will be used in scenarios that it's unplanned and
  suboptimal for.


i'm not saying the technical issues i raised are unsolvable, in fact
each one has been adressed in one way or the other in beast's serializers.
rather, i'm asking:
1) what exactly do we want in glib? (i.e. which use cases should be covered)
2) which use cases should be rejected by the glib implementation(s)?
3) do the answers to (1) and (2) really cover a broad range of serialization
   applications out there?

and i think one of the best way to be sure and positively answer (3) could be
the independent development of a serialization lib outside of glib.

such a library could be included into glib at a later point, once its mature
enough and has an adequate track record of applications.

> The bugzilla issue could serve as a tracker item. And now maybe some
> more people know about thsi and add their thoughts and ideas.

if you still think this should be tracked in glib bugzilla as an
enhancement, you can always reopen the report.

> @Andrew: is you implementation public? If so where can I find the
> sources, if not can you make the serialisation part public?
>
> Maybe we can find a SoC student for the next summer to look at the
> solutions used in our application as come up with a good proposal that
> suites most apps.
>
> Stefan

---
ciaoTJ