Re: XML-based sources (Metadata Factory plugin)

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

On Thu, 2012-06-21 at 19:44 +0100, Bastien Nocera wrote:

> I tried to write a source, and I couldn't find a way to debug it. It's
> impossible to insert debug of intermediate steps.
> 
> > But the point is that sooner or later, you need to deal exactly with
> > everything defined in the XML source.
> 
> That's not really the point. The point is that it's hard to figure out
> how to write it when you know what should be written, it's hard to debug
> when something goes wrong (or when a service changes), and it's hard to
> adapt sources from other systems (such as MythTV plugins) to it.

> In C, I can add a printf or attach a debugger to see what value a
> variable has in the code, or whether that code got hit. It's impossible
> with your source.
> 

I agree on that. There is no documentation at all, and right now, there
isn't any kind of support to know what's going on. In fact, most of the
sources I wrote I needed to use gdb to really know what was happening.

You don't know how a XPath is affecting the results, nor what a regexp
is doing. But I really think that having a "debug mode" when
implementing writing the sources, where lot of useful information is
shown, explaining exactly what is done, and what is happening, could
improve a lot the experience (and, of course, good documentation).

I'm not saying that this will be exactly as writing in C, where you can
put your printfs in any place, as you wish. In this point nothing can
beat C. So I agree on that.


> > * Add threads. As you well point-out in bgo#667557, this can be done
> > with GAsync callbacks/results. The point with threads is that if it is
> > not done very very carefully, it could be a can of worms.
> 
> Yes, you need to use threads, and just for the fact that you mentioned
> (it's hard to do threads right), it should be done by the framework, not
> by the plugins.
> 

Exactly! This is what I meant: you need to make the framework to take
care of them.

Would it be useful? Totally. But I think this feature needs to think
carefully how to address it. So in this point I agree with you too.

> I personally think that lua is a good match for this sort of problems,
> as it has a very small API of its own, which means we can lock-down the
> plugins, and offer a minimal API. It also stops won't trample on
> applications, and it's a good match for the work done in quvi.
> 

Maybe. I don't really know very much Lua, so dunno how to use it to
solve this problem.

But could be an option, yes.


> I don't think that using D-Bus will solve Grilo's problems though. The 2
> biggest problems are the need for every plugin to handle their own
> threading, and the lack of interpreted and easily debuggable scripting.
> 

Well, I think it would solve the problems, but I agree that probably it
is not the best approach. 

1. Each plugin is running in its own process, so you don't need to use
threads: you can do everything in your main loop and send later the
results. The UI will not blocked while waiting.

2. You can write your source in the language you want, just implementing
the Grilo's D-Bus interface. A library could be provided for facilitate
this for different languages.


So summing up the whole email: independently of this XML-based
definition of sources, I agree with you that would be really great if
Grilo:

* Uses threads to execute each source, so there is no need to deal with
asyncness inside
* Allows to implement sources using your favourite language.

	J.A.