[elinks-dev] Re: Internal goto_url_hook. (update)

Petr Baudis 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

Fine :-).

> 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
default etc).

> > 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 :-).

..snip..

Kind regards,

-- 
 
				Petr "Pasky" Baudis
.
To get something done, a committee should consist of no more than three
persons, two of them absent.
.
Stuff: http://pasky.ji.cz/



More information about the elinks-dev mailing list