Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs

[Klaus Weide]

On Thu, 13 Jul 2000, Vlad Harchev wrote:
> On Wed, 12 Jul 2000, Klaus Weide wrote:
> > On Mon, 10 Jul 2000, Vlad Harchev wrote:
> > > On Sun, 9 Jul 2000, Klaus Weide wrote:
> > > > Another problem is that we haven't even defined what we are talking 
> > > > about.
> > > > There are many ways in which lynx can be made to send mail (already, 
> > > > with
> > > > its built-in code).  Try to come up with a list as an exercise, it 
> > > > should
> > > > have at least 5 or 6 entries... only one of which is "following a link 
> > > > to
> > > > a mailto: URL".

> > On the one hand, you think now your first patch isn't good because it
> > isn't general enough, it handles only a special case: ACTIVATE on a
> 
>       It was not only on mailto:, but on any URL based on prefix matching.

Yes, but right now we are discussing in the context of alternatives for
handling mail, aren't we?  (As an aside, handling some other URL types
like all "ftp:" via some external command makes it much *more* desirable
to have a way to fall back to lynx's default handling.  That's why I think
that a CERN rules based translation, which applies to *all* ways an URL
can be entered or accesed, is less powerful in a way than an ACTIVATE-
key-specific action.)

> > mailto link.  On the other hand, it's perfectly fine with you to handle
> > some kinds of mail sending with an external program, but not all of
> > them?
> 
>    We are talking about calling MUA, not MTA - so most items in the list 
> below 
> should be handled as they are now.

Yippie, we are making some progress here.  As far as I remember, this is
the first time in these discussions about hooks for mailing that someone
makes this distinction explicitly, for expressing the requirement.  Most
of the previous discussion was in diffuse terms like "configuring which
mailer to use".

> > Realize that any of the recently discussed "solutions" don't apply
> > to comments sent with the COMMENT ('c') key.
>  
>    This can be easily hacked in. 

In principle, yes.  Maybe not so easily if all the details of
setting the default subject are to be preserved.

> > Realize that any of the recently discussed "solutions" don't apply
> > to mail that is sent when a FORM with ACTION="mailto:..."; is submitted.
> 
>    It shouldn't be invoked, of course.

Are you sure?

> > Realize that any of the recently discussed "solutions" don't apply
> > to mail that is sent because of MAIL_SYSTEM_ERROR_LOGGING.
> 
>   It shouldn't.
> 
> > Realize that any of the recently discussed "solutions" don't apply
> > to "Mail the file" from the "Printing Options" screen.
> 
>   It shouldn't, since user doesn't type the body of the message.
>  
> > Does this make sense?  Wouldn't a user expect that an "external
> > mail handler" (or however it is going to be described) applies to
> > all of those cases, too?  Or at least some?  Forgetting about those
> > seems just as incomplete to me as limiting a mechanism to ACTIVATE only.
> > 
> > What is the problem you are trying to solve?  The answers depends on
> > that.
> 
>   The use of MUA user asked for for going to mailto: links and (probably) for
> sending comments.

That's a first draft for a definition of the problem, but it still needs
some work.  What exactly is 'going to'?  Obviously you don't mean just
'g'oto.  But you also don't meant all ways of accessing a mailto URL -
think of FORM action.  You also don't mean 'all ways of accessing a mailto
URL except if the mailto URL came form a FORM action' - think of the
case where a user invokes ELGOTO on a mailto form's submit field.


  Klaus


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