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

[Vlad Harchev]

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

 Isn't this stack beatiful?

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

 Are you sure? If I press 'p', "mail this file", then I'm only prompted for
email address - no editing of cc:, subject:. So it looks like you are missing
something.

> > > > [...]
> > > >   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

  As currently, not supported for mailto: URLs.
 
>   HTTP/1.0 301 Moved Temporarily
>   Location: mailto:address@hidden ,

  MUA should be invoked in this case since user will have to type message of
the body.
 
> or
> 
>   RULE:Redirect mailto:address@hidden  mailto:address@hidden ,

  Don't get why you give this item - it has nothing to do with mailto:
handling. Also, CERN rules for mailto: are yet not supported by lynx.
 
> 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.)

 As for FORM mailto: action - since user is not expected to type anything
(subject field, body, etc), external MUA shouldn't be invoked. 
 As for 'c' - user will type the body of the message, so external MUA will be
useful here.

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

  It looks like the rule of thumb is: if user is expected to type message body
or edit subject and cc: in given situatiuon, then external MUA will be
invoked (if enabled).
 
> 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.
>
  
  Very nice trick. I would like to see it included in /samples too.

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

 Yes, some light is shed.

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

 Best regards,
  -Vlad


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