[elinks-dev] Re: Internal goto_url_hook. (update)
pasky at ucw.cz
Fri Oct 3 16:14:57 PDT 2003
Dear diary, on Sat, Sep 27, 2003 at 08:05:28PM CEST, I got a letter,
where Karsten Schölzel <kuser at gmx.de> told me, that...
> On Fri, Sep 26, 2003 at 09:50:22PM +0200, Petr Baudis wrote:
> > Dear diary, on Fri, Sep 26, 2003 at 05:32:53PM CEST, I got a letter,
> > where Karsten Schölzel <kuser at gmx.de> told me, that...
> > > Well a new patch ;)
> > > Includes hook_get_proxy. e.g. if you want to set a proxy for kernel.org,
> > > create a option kernel_org under scripting.internal.proxy and set the
> > > value to host:port which should be used.
> > Hum. Well, first - could you please elaborate what is the "internal
> > scripting" supposed to do? How would you define it?
> I renamed it to c-hooks, which is more appropriate for the purpose:
> Some hooks written in C
> with an options interface similar to the other scripting backends.
> When plugins are available you could load this at runtime merely as
> any other backend.
Why? What's the benefit?
> > How does it differ from having the functionality just triggered from the
> > URL parser or proxy handler etc?
> I think this would make them more difficult as they already trigger one
> event when scripting is enabled. Why should we work around the event system
> which possibly can make life easier?
Well, I disagree on this one. I can't see any reason why this stuff
wouldn't be *simpler* if integrated directly, and I still fail to see
any benefits from having it interfaced by events. Or well, if you wish,
you can hook it on the events, but I still don't know why should that
stuff implementation live elsewhere.
> > Unless there will be some hidden value shown in this "internal
> > scripting", I think I don't want it in ELinks. It seems like bloat and I
> > personally see no real value in it. I'm ready to be enlightened, though
> > :-).
> I thought it would be nice to have some testing of the event system
> through another backend. It could also be a testcase for a plugin with
> an options interface.
> It already helped to specify when to use EHS_LAST and EHS_NEXT ;-)
That's fine then. But I'm not sure I want that integrated. Perhaps as a
'test' scripting module doing something dummy, with some special
constraints regarding visibility to the user (ie. not being built by
> > Some generic comments follow. Some of them about general issues and some
> > of them might be valuable when actually integrating the internal
> > prefixes somehow.
> > > Index: configure.in
> > > ===================================================================
> > > --- configure.in (revision 306)
> > > +++ configure.in (revision 314)
> > > @@ -405,6 +405,20 @@
> > > AC_MSG_RESULT($cf_result)
> > >
> > > dnl ===================================================================
> > > +dnl Check for `internal´ scripting option set.
> > > +dnl ===================================================================
> > > +
> > > +enable_internal="no";
> > > +
> > > +AC_ARG_WITH(internal, [ --with-internal enable internal scripting support],
> > > + [if test "$withval" != no; then withval=""; enable_internal=yes; fi])
> > > +
> > > +if test "$enable_internal" = "yes"; then
> > > + AC_DEFINE(HAVE_INTERNAL)
> > > + AC_DEFINE(HAVE_SCRIPTING)
> > > +fi
> > "INTERNAL" is too ambiguous.
> I have changed the name this to c-hooks, so this is now C_HOOKS which is
> more descriptive I hope.
Sure. Good move :-).
Petr "Pasky" Baudis
To get something done, a committee should consist of no more than three
persons, two of them absent.
More information about the elinks-dev