Re: lynx-dev [PATCH]

[Klaus Weide]

On Sat, 8 Jul 2000, Vlad Harchev wrote:

> On Fri, 7 Jul 2000, Klaus Weide wrote:
> 
> > On Fri, 23 Jun 2000, Vlad Harchev wrote:
> > > On Thu, 22 Jun 2000, Mike Castle wrote:
> > > > Also, let's say, instead of using the EXTERNAL command, the user wants 
> > > > to
> > > > use the standard built in lynx command occasionally.  What's the 
> > > > mechanism
> > > > for that?

> > > (so there won't be any way to get
> > > standard built in lynx functionality).

I still don't think that's good.

> > Here are two ideas to extend the EXTERNAL-based approach.
> > 
> > 1. Don't make ACTIVATE run EXTERNAL commands.
> > Instead, make a new lynx key action ACTIVATE_OR_EXTERN (or

>  I already told about my attitude towards extending EXTERNAL.

But you didn't really tell why, or did I miss it?

> But anyway I
> think that separating ACTIVATE and ACTIVATE_OR_EXTERN is a bad thing.

Again, why?

It gives more choice to the user.

> > 2. Extend EXTERNAL as follows:

> >    # EXTERNAL:<url>:<command> %s:<norestriction>:<allow_for_activate>

>   If functionality like this (binding several actions to one type of URL) is
> desired, then IMO it's better to use plain EXTERNAL command and meta-wrapper
> that will ask "press 1 for running blah, press 2 for running foo, press 3 for 
> running baz". This is much more flexible and reasonable.

Sure, you can do that; I have actually made such a script for myself
(but don't use it often anyway).

I just think the above would be a logica extension that doesn't require
much extra effort or code, *if* you were to extend the EXTERNAL mechanism
anyway.

> > In any case, whether the abocve is used or not: As soon as Enter/Return
> > or an Enter/Return-like key can run EXTERNAL commands, *there should be
> > a mechanism for protection*.  Like the TRUSTED_EXEC mechanism, where

> > IOW, something like the TRUSTED_EXEC / TRUSTED_LYNXCGI mechanism should
> > be applied to "auto-invoked" EXTERNAL commands, too.
> 
>  I think efforts should be redirected to securing lynx{prog,exec} and to
> allowing mailto: to be subject of CERN rules (using the patch you'll suply)
> and to supporting external handler for mailto: urls. 

Securing lynx{prog,exec}: good luck.  Are you going to do it?
The kind of people for whom this mechanism was primarily intended, and who
invented and extended it, have all left the building (read: are not active
on the list any more).  It's fairly hard to understand how even the existing
protections are supposed to be used and how they work together.

Supporting external handler for mailto: urls:  In order to provide (at least)
the same functionality as lynx's built-in handler, the interface for hooking
in an external mailto-handler will have to be mailto-specific.  No generic
mechanism will do.

> I think that CERN rules
> should be primary mean for achieving
> "ACTIVATE-and-all-other-commands-invoke-user-configured-handler-for-given-URL"
> functionality.

Maybe, but achieving
"ACTIVATE-and-all-other-commands-invoke-user-configured-handler-for-given-URL"
functionality was not what the request for an external mailto-handling command
was about.  It was about "ACTIVATE-invokes-user-configured-handler-for-given-
mailto-URL".

   Klaus






; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden