r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Anton
16-May-2006
[4419]
If so, then that's not how it's supposed to work. BCC really does 
mean "blind carbon copy". The recipient should have no way of knowing 
other addresses. Your only standards-conformant remedy is to use 
CC.
Henrik
16-May-2006
[4420]
is system/locale ever used for anything beyond the date requester? 
it would be nice if it were possible to localize date! type
Gabriele
16-May-2006
[4421x3]
send - i think there is a lot of confusion here
the BCC header field is a field used by mail clients to let users 
type addresses that will *not* be included in the header. it is, 
basically, a user interface. back at the time mail clients did not 
have a gui, and just processed mail from a file or by letting you 
type them on the terminal
so what a mail client does, is reading the mail, collecting the addresses 
from to, cc, and bcc, removing the bcc lines, and then sending the 
message to the collected addresses.
Pekr
16-May-2006
[4424]
yes, B should stand for Blind .... it should prevent disclosing the 
person, you sent copy to ....
Gabriele
16-May-2006
[4425x6]
but send is not a mail client. it is a function to send email messages.
what send does (and should do!) is sending the specified message 
to the specified list of addresses. send does *not* collect the addresses 
from the mail header.
to make things easier, send will fill in a default mail header if 
the user has not provided one. however, if you are after something 
more complex than send [luke-:-rebol-:-com] "hi!" then you probably will 
want to pass your own header.
this header is sent as-is, except for a couple things such as setting 
To if you haven't set it (this is so you can have a header template 
and send many messages with it easily)
what send does *not* do and *should not* do is remove or change other 
header lines. in particular it will not remove any bcc: lines. the 
reason is, that you should *not* pass them at all, because it makes 
no sense.
now, since this is a very common error among users, it may be useful 
to let send remove bcc. personally, i will vote against this, because 
i prefer educating users (documentation) rather than keeping them 
stupid and happy. ;) even in the case we do it, send is still *not* 
collecting the addresses from bcc anyway - so we're just wasting 
time removing something that someone wasted time adding.
Graham
16-May-2006
[4431]
how about implementing an 'email function that does bcc etc?
Gabriele
16-May-2006
[4432]
so what you need to do now to send a message is - just send/header 
[list of addresses] msg header, with header being composed correctly 
- to should have what you want your recipients to see in to, from 
should have what you want your recipients to see in from, and so 
on; there should *not* be any bcc lines.
Graham
16-May-2006
[4433]
It just needs to wrap around send.
Gabriele
16-May-2006
[4434x2]
graham: that's a good idea and the desktop already has something 
like that, a gui that lets you type to subject and message. we could 
just add bcc and cc
also, i think there are a couple of mail clients written in rebol 
around :)
Graham
16-May-2006
[4436]
Something basic that can be enhanced by the user so this confusion 
is cleared up permanently
Gabriele
16-May-2006
[4437x3]
yes, but is it easier to write:
email [to: [graham-:-somewhere] from: [me-:-here] bcc: [carl-:-there] subject: 
"something"] msg
instead of using send directly?
Graham
16-May-2006
[4440x2]
looks good
email/attach
Volker
16-May-2006
[4442x4]
IMHO that are to much internals. I would add bcc to send. First, 
if you use bcc, its almost 100% a privacy issue. So at least no bcc. 
Second, users read "email", they know email and email has bcc. What 
happens inside the mail-client they have no clue. So bcc should also 
be added to the header-list IMHO. At least as option, send/bcc or 
such. Should not be much parsing and things works a lot more right. 
As this discussion proves.
But interesting thread :)
header-list -> recipient-list
'sends first argument.
Gabriele
16-May-2006
[4446]
volker, i'm not sure what you're suggesting.
Volker
16-May-2006
[4447x3]
To pass recipients in the bcc too, parse that.
  send/header [x-:-y] text [bcc: "[a-:-b]"]
-> mail goes to [x-:-y] and [a-:-b]
and bcc is cleared.
IMHO that is straightforward without guru-knowledge.
Gabriele
16-May-2006
[4450x4]
doesn't make sense - it should parse to: too in that case, and the 
address list would just be discarded?
better to allow something like the email function above
send [to: ...] msg     where send detects this checking for a set-word?
it seems to only add confusion to me. ymmv.
Volker
16-May-2006
[4454x2]
Not mm, Brocks. "Joe, I had problems with BCC in a corporate mass 
emailing I did.  Even though it did not display the email address 
in the mail client, if you viewed the header of the mail message 
the BCC content was there."
And yes, if i put 'to in the header in my client, i expect it works 
in send/header too.
Maxim
16-May-2006
[4456x3]
we need refererence manuals like python has.  which explicitely state 
every limit and all intended useages of any and all words and refinements.
we keep guessing many things and not many of us use things like 'source 
to figure things out (when its even possible)
currently we have a brief dictionnary with SOME but not all of the 
information.
Volker
16-May-2006
[4459]
No, we need compatibility with common uses. Python maybe not, python 
has no "email!" AFAIK. But rebol has, creates an illusion and breaks 
it on the next possibility, leading to this bcc-thing.
Anton
16-May-2006
[4460]
No we don't. A programmer who wants to know how the mail system works 
should read existing standards documents.
Maxim
16-May-2006
[4461x2]
come one Anton... you expect the mass to have time to read explicit 
out of language dry docs?
if a language has a feature which supports something, it has to explain 
exaclty how it does it.
Volker
16-May-2006
[4463x2]
I like that
  send [to: ...] msg
send [to: [x-:-y] subject: "i am back"] "had great hollidays"
Maxim
16-May-2006
[4465]
send  is just the example of what the word does SOME things more 
than it should, but not all, and does not fully explain everything. 
 We are used to a lot of consistency in rebol. and if a word makes 
email shortcuts but not all of them... I understand the frustration 
which can come from a mistake, when you can't really know how -REBOL's- 
mail handling is performed... no matter what are the standards.
Volker
16-May-2006
[4466x2]
But, how about dropping 'send and switching to 'email completely 
in R3? 'send is a nice word for rebservices etc. IIRC Carl noted 
that somewhere.
Then in case of email 'send could be stupid without *any* headers, 
and 'email the dialected smart version.
Maxim
16-May-2006
[4468]
http is supposed to be handled in rebol, yet I had to rewrite my 
own http-post function to talk to a webservice operating only in 
http1.1 of which rebol had a lot of trouble handling.  yet the service 
was compliant and rebol was not.