Re: State of bindings

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Thu, 2011-06-09 at 16:47 +0200, Guillaume Emont wrote:
> 1/ Things that would require fixing in Grilo
> 
>  - lack of support for the life length of our callbacks and associated
> user data: right now, only works properly if a reference is kept on the
> python/js/whatever side, to ensure it isn't destroyed. This might need a
> change on our async API (see "Scope types"[1]).
>  - things would be more pythonic if "properties" were available as
> instance properties instead of through getters/setters. I'm not sure yet
> of how to do this, but I suspect that having all these implemented as
> proper GObject properties could do it. Need investigating to make sure
> of that.
>  - I don't think we can write (and load) a source in python or
> javascript.  There's probably not much to do for that to work in python,
> since pygobject allows you to subclass GObjects in python. What's
> missing is a way to load python sources and a lot of testing. To load
> the sources, we could do something like GStreamer's python plugin[2]. It
> basically looks for gstreamer elements in predetermined paths, and make
> them available like any C element to applications.

So, from what I understand, the main problem is with the callbacks.

The second issue is not causing a real problem, as far as I understand.
But for what is worth, some time ago, I've been checking the possibility
of getting properties from GrlData using gobject properties. I think I
have a branch in some place. I recall there was a bug in glib that
prevented to work it fine (a bug that was causing due an
over-optimization in a fix for a different bug). Maybe we can retake it.

For the third issue, I would really like to have a way of loading
plugins in other languages. Maybe gstreamer approach is a good choice.
Another one would be writing the dbus-based server, so really one could
write plugins in virtually any language.

	J.A.