[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!
> 
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