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 Thu, 13 Jul 2000, Klaus Weide wrote:
> > 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".

> > 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.)
> 
>  I don't think so for some reason. As for getting original behaviour
> conditionally, user can define EXTERNAL command that will invoke lynx with
> -cfg=/some/other/cfgfile/that/does-not/force/total/redirection/of/that/url/type
> commandline switch, like EXTERNAL:ftp:lynx -cfg=/dev/null %s

So the cost is maintaining two different lynx configurations, two lynx
processes, and a nonobvious trick.

       ------------------------

> > >    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
> 
>   You offend me.:)

That wasn't the intention....

> > makes this distinction explicitly, for expressing the requirement.  Most
> > of the previous discussion was in diffuse terms like "configuring which
> > mailer to use".
> 
>   Klaus, what else you think we could be talking about in this thread? I
> wonder.

I didn't know, that is why I was asking.

Well, it was more or less clear that here, in _this_ thread, you were
talking about invoking a MUA (without exactly saying when and when not).
But we were also talking about "handling mailto URLs" or "mailto: specific
handler", and you seem to have raised "total interception" as some kind
of ideal; that would indicate that mailto FORM actions are included.
And with previous discussion I meant earlier threads, where things were
more unclear.

> > > > 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.
> 
>   May be.
> 
> > > > 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?
> 
>   This is the same case as with "Mail this file" - user i snot expected to
> type anything - so using MUA is not necessary.

Not strictly true that the user is not expected to type anything.
The user is prompted for some headers in mailform():
    /*
     *  Allow user to edit the default Subject - FM
     */
  .....
    /*
     *  Allow user to specify a self copy via a CC:
     *  entry, if permitted. - FM
     */

That's arguably part of a MUA's function, what lynx does here.


> > > > 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
> 
>   I meant 'x','g','G','E' and ACTIVATE commands (probably I missed some other 
> exotic comand, but unlikely).

HEAD?  'd'ownload?  or

  HTTP/1.0 301 Moved Temporarily
  Location: mailto:address@hidden ,

or

  RULE:Redirect mailto:address@hidden  mailto:address@hidden ,

is that also 'going to'?

> > '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
> 
>   It seemed to me that LYSubmitForm handles this specially, without
> using LYGetfile.c, did I miss something?

Yes, I know it is handled specially.  That doesn't answer the question
whether it _should_ be.  (COMMENT ('c') is also handled specially -
but in that case, you _want_ to handle it non-specially according to
above.)

> > 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.
>    
>    MUA should be used in that case - what's the problem? I don't think that we
> are going to track how the given URL came to recall list - IMO it's a bad
> idea.

The problem is how to describe exactly when your proposed MUA replacement
feature applies and when it doesn't, for documentation in lynx.cfg and
maybe Lynx_users_guide.  (Also, how to call the feature/option.)  If it
can't be described simply and accurately, then maybe it's too complex
or not well designed.  If it's easier to say "this option applies to all
mailto URLs" rather than "this option applies to all mailto URLs except
for [long explanation]", then maybe "applies to all mailto URLs" _is_ the
more logical behavior.

I'm just raising questions (don't I always? :) ), I leave it to you to
answer them the way you like (don't you anyway? :) ).

     ----------------

Anyway, the way _I_ hook an "external mailer" into lynx is described
here:
   Linkname: Lynx-Dev Archives: LYNX-DEV Customizing sent mail
        URL: http://www.flora.org/lynx-dev/lynx-dev/9609/0443.html

That always gives me a chance to review _any_ outgoing message, however
the sending was initiated within lynx (the issue w/ SYSTEM_MAIL vs
system_mail mentioned in that URL doesn't exist any more).  I have access
to all headers and the body as pre-composed by lynx's normal handling.
No accidentally sent "mu mu" messages (except when testing some _other_
means to send mail...).  This always worked, whatever many changes were
made to the higher level mail code in lynx.  

Yes, I'm hooking an MUA into a place that is apparently meant as an
interface to a MTA.  Not that lynx.cfg says so explicitly...  it just
talks about "mail command and qualifiers", or "mail path and flags".
Oh, and the "MAIL" command used for VMS is really an MUA too.
And this is the only documented interface for hooking in an external
mail command of any form (MUA or MTA), as for as I can see.

Maybe this sheds some light on why I ask apparently silly questions
about what exactly you mean.

 Klaus


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