[elinks-dev] Use event system to call lua functions

Karsten Schölzel kuser at gmx.de
Sat Oct 4 05:25:18 PDT 2003

On Sat, Oct 04, 2003 at 01:57:28AM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Sep 30, 2003 at 02:28:56PM CEST, I got a letter,
> where Karsten Schölzel <kuser at gmx.de> told me, that...
> > Two patches are appended:
> > * the first adds scripting/plugin.[ch] with (un)load_plugin, which can
> >   be used to load and unload a plugin at runtime. Currently the
> >   interface to use this is missing (dialog, options !?). But builtin
> >   scripting backends are handled by the plugin layer.
> >   It also adds a layer to scripting/scripting.c to make it possible to
> >   bind keys from different backends.
> ..snip..
> Well, it after all does not look that bad as I thought when I had my
> first look at it ;-).
> The general plugins managment stuff looks useful, however I don't like
> tight integration of dl stuff into that. Please introduce it without dl
> first, just register_plugin() & co.
> My idea is that dl should live in own module, sorta "bridge" - it would
> be scripting/so/ or so (most of the scripting/ stuff will have to be
> generalized later to modules/ anyway, so the little dis-proportion in
> the "scripting" name and this module operation doesn't matter to me, as
> long as it is useful and has clearly-defined scope of operation and
> purpose), cleanly isolated from the rest of the stuff and nicely
> optional and OS-specific etc.
> My idea is that the 'so' module would just export few relevant functions
> to the dlopen()ed plugin (table passed to the module through some
> defined entry-point function?) (I think only the events-related stuff,
> it shouldn't need anything else; we should decide whether it should link
> against libutil.a on its own or we should export that thru a table as
> well). Then, it would probably yet do the register_backend() call for
> it, and from that point on, the module would live on its own exactly as
> a builtin one, and the so's "bridging" would be practically invisible.
> So 'so' would turn out to be rather trivial module, just loader/unloader
> for shared object modules. What do you think?
The docs about dlopen and libtool mention that the global symbols of the
program are visible for the module if the program is linked with
'-rdynamic' (and/or '-export-dynamic'). So you wouldn't need to link the
modules with libutil.a to access its symbols. But I don't no what to
prefer ;)

> As I said about the scripting -> modules move... Well, scripting should
> be really only for scripting backends, nothing more. However, there is
> going to be more modules than scripting backends in the future, which
> all should take advantage from the events web when sufficiently dense.
> Some of them will probably live in modules/, but some may not (ie. UI
> toolkit multiplexer or terminal backend multiplexer?). Possible examples
> of candidates for modules include bookmarks, global history, forms
> history, maybe cookies, MIME backends etc. Anyway, this is again just
> sound of the future, nothing to worry about now but perhaps good to bear
> in mind.
> (Another notice - please don't move/rename files or even directories on
> your own, ask me instead. I will do it in CVS directly, thus preserving
> correct history etc.)
> Anyway, the *generic* plugin stuff looks fine and has my ack, the move
> of plugins list administration is a good move from my POV to the ideal
> distribution of stuff :-). Separation to sub-patches would be
> appreciated.
> About 'so' module, let's first get the generic plugin stuff in. Then,
> this plugin may be introduced. I'd leave it by default off for now,
> until it will be actually useful. It also must properly check if the
> system offers the necessary stuff (dlfcn.h, -ldl, dlopen()) and decide
> on how (if ever) will it compile itself based upon that.
> What do you think?
Libtool offers some functionality through a lib called 'libtldl' which could
be use in favour of directly using dlopen, as it is (claims to be) more
portable. I need to investigate it further, so that this plugin stuff
is cued for later rework ;-)

> Thanks!

> PS: By the way, what would you think about the terminology shift plugin
> -> module ?  Ideas welcomed.
When comparing both names, plugin seems to mean something that is always
external and needs to be plugged in, whereas module doesn't. So module
is a better name.

> > Index: src/scripting/scripting.c
> > ===================================================================
> > --- src/scripting/scripting.c	(revision 341)
> > +++ src/scripting/scripting.c	(revision 351)
> ..snip..
> > +int
> > +register_scripting_func(int call_event_id, int unref_event_id, int func_ref)
> Uh. Could you please explain this stuff? What's it good for?
That is obsolete stuff, it was meant for keybinding for scripting
backends. But the addition of the data pointer to event_hook made it
much more simpler to implement in another way. ;-)

Karsten Schölzel

More information about the elinks-dev mailing list