On Wed, 25 Feb 2015, Michiel van der Vlist wrote to Kees van Eeten:

 MvdV> Puting a req on hold does not make much sense to me, so let the 
 MvdV> *.req do it all by itself.

why not? we used to do that all the time... then the remote would pick it up
and deliver the file on its dime... that's why there was created the mailer
option to not pick up file requests that may be waiting at the remote...

 KE>  The actions of the BSO construct respect connection rules that may
 KE> not be opportune to BINKD, but are still valid.

 MvdV> I like to look at it from the perspective of someone not loaded
 MvdV> with the prejudice of how it was done in the past.

so "you" want to replace your car with its rubber tires with an old open
goat-drawn wagon with solid wooden wheels? the analogy is that "you" are
advocating reversing all the technical capabilities that have been developed
over the years while we climbed out of the stone age... "you" are wanting to
return to the stone age is how "your" statements are understood by others...
"you" in quotes because you, personally, are not the only one saying similar
things...

 KE>  For how you want to work, you can use mailboxes, these are not 
 KE> part of BSO.

 MvdV> Ok, so let the option of having a *.req file initiate the 
 MvdV> connect all by itself be a similar add-on.

/if/ the maintainers decide to do it, it may very well appear ;) 

 MvdV> Just a thought... If I were to redesign it from the start, I
 MvdV> would either: 

 MvdV> 1) Define the same five flavours for *.req as for *?lo and *.?ut 

 MvdV>    .req   =  normal
 MvdV>    .ceq   =  crash
 MvdV>    .ieq   =  immidiate
 MvdV>    .deq   =  direct    ( I do not know how meaningful NOT direct
 MvdV> is..)    .heq   =  hold

 :) 

 MvdV> 2) Drop the xxxxyyyy naming requirement for *.req, and have them 
 MvdV> listed in a *.?lo file for sending, just as any other file that 
 MvdV> is to be send.

that can be done now :) 

 MvdV> As it is, it is an illogical mix of both...

i don't know why... the best of both worlds and capabilities...

)\/(ark