help with mail attachment please
[1/12] from: dk-photo:home at: 9-Aug-2001 10:40
I haven't looked at Rebol in over a year. But it seems like every time I
try to find a use for it, I get sideswiped by a limitation...
I have a client with a problem, towit: He has to put his mail server on a
separate machine from his HTML server if he wants to script email
attachments with his current setup. (Macintosh server, WebStar, Lasso).
He doesn't want to set up a separate email server.
I thought that since Rebol was so simple it could send an email in one
line of code, it might be an ideal solution, so I dusted off my Rebol
stuff and started digging;
Bang! Clipped already. It seems Rebol cannot send an email attachment, at
least not easily. For 'messaging' software, this seems like a ridiculous
shortcoming! I found attach.r, but it is not commented and there are no
examples, so I cannot get it to work. I get syntax errors galore. And
even if I could get it to work, I still don't know if Rebol's other
shortcomings won't prevent me from using it anyway.
Is there still no way to 'send a message' to this 'messaging software?' I
don't want to use Rebol as a cgi (BTW, does anyone know if WebStar will
work with Rebol?), and it seems on first glance at the latest version,
that there is still no way for me to call it directly with a set of
parameters from any other program, such as AppleScript. Is that correct?
You know, it's really great that Rebol can be called as a cgi, but if
there is no other way to call it, then that's all it is... just another
cgi language. Surely I am not STILL the only person who sees how vital
and basic it is for program X to be able to launch Rebol and pass it a
handful of parameters!?
A rapid response would be much appreciated. I have already lost two days,
re-reviewing Rebol and need to move on to a solution that will work, if
Rebol will not.
TIA
David Kachel
theMac Workshop
http://www.macworkshop.net
Democracy is five wolves and a sheep voting on what to have for dinner.
Liberty is a well-armed sheep contesting the election.
-unknown
They that can give up essential liberty to obtain
a little temporary safety, deserve neither liberty
nor safety.
-Benjamin Franklin
Millions of sniveling cowards shivering in the corner,
begging government to protect them from every threat,
real and imagined,
have stolen liberty from the rest of us.
A government drunk with power, gleefully complies.
-David Kachel
...(paraphrasing Benjamin Franklin)
[2/12] from: ryanc:iesco-dms at: 9-Aug-2001 12:19
It would be nice if 'Send supported attachements. Anyways, here is how you
use Sterling attach.r:
>> do http://www.reboltech.com/library/scripts/attach.r
>> help mail
USAGE:
MAIL mesg headers files
DESCRIPTION:
send a message with attached files
MAIL is a function value.
ARGUMENTS:
mesg -- the message body (Type: string)
headers -- headers object; usually made from system/standard/email (Typ
e: object)
files -- list of items to send; files will be loaded,
other objects should be listed as [attachment-name object] (Type: block)
>> msg-header: make system/standard/email [to: [ryanc--iesco-dms--com] from: rya
[nc--iesco-dms--com]]
>> mail "TEST" msg-header [%test.gif]
reading file: test.gif
== [
make object! [
To:
CC: none
BCC: none
From: [ryanc--iesco-dms--com]
Reply-To: none
...
>>
There does seem to be a problem with the 'to field being eaten. I dont know
why, but you might confirm this, and email sterling for a solution. You might
mention to him to add some usage comments in the header section of the
script. Other than that, it works fine on my end. If you have a suggestion
for the ultimate email function, please post it to the list, a few of enjoy
that sort of thing.
BTW, have you used View lately? I use /Core for all kinds of things, and
View is some slick stuff. I have written well over a hundred scripts, and
only a dozen or so were CGI's. I think your missing something.
--Ryan
David Kachel wrote:
> I haven't looked at Rebol in over a year. But it seems like every time I
> try to find a use for it, I get sideswiped by a limitation...
<<quoted lines omitted: 46>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
[3/12] from: dk-photo:home at: 10-Aug-2001 10:51
Ryan Cole said:
> msg-header: make system/standard/email [to: [ryanc--iesco-dms--com] from: rya
>[nc--iesco-dms--com]]
> mail "TEST" msg-header [%test.gif]
>reading file: test.gif
>
Thanks. I got it to work, sorta. There were a couple of problems. Perhaps
you can clear these up for me;
1. The above worked just fine when I sent a small file. But when I tried
to send a somewhat hefty PDF (4+ megs, the actual type of file we will be
attaching), Rebol told me it didn't have enough memory. A second attempt
to send the overweight file caused Rebol to crash and burn. Here's the
exact error message:
** Script Error: Not enough memory
** Where: mail
** Near: append mesg line-break enbase either
I tried increasing Rebol's memory partition. Result: crash and burn again!
2. The above syntax on my system sends the string "TEST" as the body of
the email, with no Subject line, which of course many email
servers/software will reject or choke on. How do I get something into the
subject line?
>There does seem to be a problem with the 'to field being eaten.
Could you elaborate on that? Exactly what happens?
>BTW, have you used View lately? I use /Core for all kinds of things, and
>View is some slick stuff. I have written well over a hundred scripts, and
>only a dozen or so were CGI's. I think your missing something.
I think you may have missed my point:
Can View (or CORE for that matter) be launched from anything on a Mac and
passed parameters? In other words, can any software OTHER THAN REBOL OR A
WEB SERVER, activate and pass a function name along with parameters to
Rebol, on which information Rebol can then act? Or is Rebol simply a lump
that requires me to physically launch it with a mouse and input calls
from the keyboard?
<RANT ON>
As I understand it, Rebol easily responds to such 'messaging' on any
flavor of Unix, and even on, ugh, Windblows(?). Why on Earth is it
considered unimportant to do the same on a Mac? If it were the *nix
platforms that lacked such obviously needed functionality, there would
certainly not be a similar failure to "get it" at Rebol.
It's not as if such implementation would be difficult either! Only four
commands would be required:
Activate/Launch/Run
Quit
DoScript() with()
Return
What's more, since Rebol can already react to a call from a Web server
and accept parameters from it, that means that the plumbing for the above
is already largely in place. It's as if the plug is lying on the floor
and the folks at Rebol refuse to pick it up and plug it in!
Here's what I need to do:
1. Client submits form to Web server.
2. Web server calls my already in-place cgi, sending along the usual form
text.
3. My cgi uses the info sent along by the web server to update a couple
of databases and then (because the cgi software is properly conversant
with the rest of my system) sends a call to Rebol (OR TO VIRTUALLY ANY
OTHER SOFTWARE AVAILABLE FOR THE MAC OR IN THE MAC SYSTEM ITSELF),
which...
4. Sits there and does nothing, because Rebol can't take any calls from
anything except a web server, but if it could, would package up an email
with an attachment and send it out.
Now in theory, I could presumably have the web server call Rebol first,
which could then successfully package and send my email. But the next
thing Rebol would have to do is call the aforementioned cgi, which of
course it cannot do, because Rebol is 99% mute!!! Or, I could have Rebol
perform the cgi behavior itself, but then... Rebol is still mute and
can't do that either.
Now the above is the way Rebol behaved (or failed to behave) when I
looked at it the first, second and third times. If things have changed
and I have simply failed to see it, I would LOVE to be corrected.
Someone, Carl(?), PLEASE correct me! I would be overjoyed to eat crow.
But until someone can make me chew on black feathers, this so-called
universal cross-platform software is not universal or cross-platform at
all! If I can write a shell program on Linux that calls Rebol, sends it
parameters and makes it jump, then I should be able to do exactly the
same thing on any other platform, including the Mac, which accomplishes
such things through APPLESCRIPT !!!!
The court finds the entire Rebol staff guilty and sentences them to
forever code in Fortran... I feel so much better.
<RANT OFF>
David Kachel
theMac Workshop
http://www.macworkshop.net
Democracy is five wolves and a sheep voting on what to have for dinner.
Liberty is a well-armed sheep contesting the election.
-unknown
They that can give up essential liberty to obtain
a little temporary safety, deserve neither liberty
nor safety.
-Benjamin Franklin
Millions of sniveling cowards shivering in the corner,
begging government to protect them from every threat,
real and imagined,
have stolen liberty from the rest of us.
A government drunk with power, gleefully complies.
-David Kachel
...(paraphrasing Benjamin Franklin)
[4/12] from: woodward:shore at: 10-Aug-2001 13:39
On Fri, 10 Aug 2001, David Kachel wrote:
> I tried increasing Rebol's memory partition. Result: crash and burn again!
That may have more to do with the relatively poor memory handling under
MacOS than anything else - I'm assuming you're using 9.x not OS X? Under
various flavors of Windows it's not unusual for REBOL/View to consume 70MB
or more running what I think of as light-weight scripts (with a fair
amount of image data - which I would imagine would be similar in footprint
to PDF data).
> I think you may have missed my point:
> Can View (or CORE for that matter) be launched from anything on a Mac and
<<quoted lines omitted: 3>>
> that requires me to physically launch it with a mouse and input calls
> from the keyboard?
<rant>
If you had a command line, maybe?
Sorry - couldn't resist the jab.
</rant>
I've never had any problem invoking scripts with a variety of arguments
from Linux, Solaris, or Windows. Of course, they all have a fairly robust
command line interface. It's been a long time since I've had to script
anything on a Mac (I used to use AppleScript and HyperCard pretty
extensively 5 or 6 years ago) - but I do recall as there was some way to
invoke apps with parameters from within AppleScript. It may simply be
that you'll want to create a wrapper in AppleScript to call REBOL scripts.
I'd imagine this seems pretty stupid - but it's an unintended consequence
of the over-reliance on a GUI...
Other stumbling blocks include a lot of non-standard interfaces and APIs
on the Mac, and I would suspect that (unfortunately for you) market share
is a relatively large driver for REBOL development. On a standard CGI
interface it should be possible to invoke REBOL fairly easily w/o using
any AppleScript - but it really depends on the Web Server you're using.
> <RANT ON>
> As I understand it, Rebol easily responds to such 'messaging' on any
<<quoted lines omitted: 43>>
> forever code in Fortran... I feel so much better.
> <RANT OFF>
Have you considered maybe that some of the limitations may be due to
barriers provided by the underlying system? I'm sure they can be overcome
on OS 9.x but you have to ask yourself is it worth REBOL techs time and
effort - especially with the superior OS X is available and shipping as
standard on new Macs (and oh yeah - it's really Unix under the hood)?
- Porter
[5/12] from: g:santilli:tiscalinet:it at: 14-Aug-2001 12:21
Hello David!
On 10-Ago-01, you wrote:
DK> I think you may have missed my point: Can View (or CORE for
DK> that matter) be launched from anything on a Mac and passed
DK> parameters? In other words, can any software OTHER THAN REBOL
It can on ANY OS I used it on so far (AmigaOS, Linux, Solaris,
Windows...). I don't want to start a flame war, but if it doesn't
on the MacOS, I would blame the MacOS, not REBOL. Apple never got
to do something right (when they were close to, Jobs arrived and
scrapped everything).
Ok, anyway, I think RT should fix this, but I suspect this is not
high on their priority list. If MacOS supported more
standard/usual ways to pass parameters, this would be already
working. (The fact that it works on Web servers is a proof: they
use a standard way to pass parameters.)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[6/12] from: holger:rebol at: 14-Aug-2001 9:59
On Fri, Aug 10, 2001 at 10:51:26AM -0600, David Kachel wrote:
> I think you may have missed my point:
> Can View (or CORE for that matter) be launched from anything on a Mac and
<<quoted lines omitted: 7>>
> flavor of Unix, and even on, ugh, Windblows(?). Why on Earth is it
> considered unimportant to do the same on a Mac?
REBOL does not "respond to messaging" in order to process parameters.
Unix, Windows, AmigaOS, BeOS etc. all support industry-standard program
arguments (argc, argv), passed to the program when it is started, and those
are parsed and interpreted by REBOL. Unfortunately MacOS does not support
this, but requires proprietary methods for that (AppleScript, I assume).
REBOL/View on Mac DOES support opening a script with OpenDocEvent (basically
clicking on a script icon, causing View to be start and execute the script),
but this does not help in passing arguments, because MacOS does not appear
to support anything resembling "command lines".
> It's not as if such implementation would be difficult either! Only four
> commands would be required:
No, it is more complicated than that. Part of the problem is that MacOS
does not allow multiple instances of an application to run simultaneously,
i.e. unlike all other operating systems it does not support a model in
which an application is started with certain arguments such as a script
name, does its work, and then quits, and multiple such instances can run
in parallel.
Instead MacOS forces an application to multiplex internally, based on "document"
handles. This may be fine for GUI-heavy applications which sit in an event
loop most of the time, but it is a big problem for applications which are
primarily "processors" (e.g. interpreters) and have an inherently stateful
execution model. This is why REBOL/View on Mac clones itself during
installation, allowing multiple instances of REBOL to run at the same time,
as different binaries. Apparently this is the only "solution" to this problem
on MacOS.
> Now in theory, I could presumably have the web server call Rebol first,
> which could then successfully package and send my email. But the next
> thing Rebol would have to do is call the aforementioned cgi, which of
> course it cannot do, because Rebol is 99% mute!!!
The next problem is that MacOS, unlike Unix, Windows, AmigaOS, BeOS,...
apparently has no system() call (or anything similar), i.e. does not
allow interaction with other applications in an industry standard
fashion, but requires proprietary methods (AppleScript again, I assume).
> If I can write a shell program on Linux that calls Rebol, sends it
> parameters and makes it jump, then I should be able to do exactly the
> same thing on any other platform, including the Mac, which accomplishes
> such things through APPLESCRIPT !!!!
If MacOS HAD a shell that provides Posix-like features and API then you
COULD do it with REBOL. It is not REBOL's fault that MacOS does pretty
much all aspects of computing differently than everyone else :-).
REAL AppleScript support (along with support for other platform-specific
scripting languages, such as ARexx) is something that is on our list.
Unfortunately at the moment other things have higher priorities. Adding
to the difficulties is that currently we do not have a real Mac expert
on staff at RT.
--
Holger Kruse
[holger--rebol--com]
[7/12] from: jeff:rebol at: 14-Aug-2001 11:04
Howdy, Holger:
> The next problem is that MacOS, unlike Unix, Windows,
> AmigaOS, BeOS,... apparently has no system() call (or
> anything similar), i.e. does not allow interaction with
> other applications in an industry standard fashion, but
> requires proprietary methods (AppleScript again, I assume).
No applescript involved, actually. AppleScript, in my
non-mac-expert understanding, is just the shorthand defacto
way of generating apple events. We do have some level of
apple event awareness, though-- most apps have to handle
_some_ apple events, including the docopen event, and a few
others.
LaunchApplication(), which is the Mac's equivalent of
system(), asks the Finder application to start and/or create
the necessary apple events to make a desired application open
up (with a document). It only took me days (weeks) of arduous
research and implementation to make LaunchApplication work
(mostly) as needed. :-)
Quickdraw: nice mac API.
Anything file or app related: painful mac API.
-jeff
[8/12] from: dk-photo:home at: 15-Aug-2001 11:48
Holger Kruse said:
>REBOL/View on Mac DOES support opening a script with OpenDocEvent (basically
>clicking on a script icon, causing View to be start and execute the script),
<<quoted lines omitted: 27>>
>to the difficulties is that currently we do not have a real Mac expert
>on staff at RT.
The above statements only serve to prove my point. I reiterate:
What we are talking about is NOT a minor feature. If *nix platforms had
no command line, you would implement the needed connections in whatever
way required.
Macs do things differently. So what! They require a different kind of
implementation, i.e., AppleScript. So what! That is the way it is done on
a Mac. And despite the fact that OS X (*nix based) does have a command
line, it STILL uses apple events and AppleScript. AppleScript will
continue to be the way such things are done on the Mac platform, by all
but the most die-hard.
Your complaint that you haven't made Rebol 'the same' on the Mac because
'the Mac is different' is at best weak and certainly leaves Rebol's
cross-platform
and "universal" claims ringing quite hollow indeed.
In short, what you are saying is: "Rebol is universal and cross-platform,
except on the Mac, because on the Mac it is inconvenient."
Depending on whose statistics you like to use, the Mac holds from 5% to
10% of the computer market. It is reasonable to assume, since a
disproportionately high percentage of web sites are served from Macs, and
because Rebol is a network-centric language, that interest in Rebol on
the part of Mac users would at the very least parallel the Mac's market
share. Which means that at least 5% of the people subscribed to this list
ought to be Mac users or at least Mac-centric. Based on what I've seen so
far in the way of responses, I'll bet the figure is substantially lower.
In fact I wouldn't be surprised to find that I'm the only one, or one of
only two or three. If I'm right, then you have already lost your battle
to become a universal/cross-platform language, because one of those
platforms, at your own insistence, has chosen to ignore you!
Do I think Rebol is better than Perl and other languages? Absolutely, and
by a wide margin. Is the concept of Rebol brilliant? Is Carl Sassenrath a
genius? Unequivocally. Will I be using Rebol? No... the people who make
Rebol don't think it is important to make Rebol useful to me because I
want to use it on a platform that is non-conforming. While the concept of
Rebol is visionary, at least this one aspect of its implementation is
not, which I believe dooms Rebol to end up on the scrap heap with the
HUNDREDS of OTHER brilliant, visionary new languages already there.
David Kachel
theMac Workshop
http://www.macworkshop.net
Democracy is five wolves and a sheep voting on what to have for dinner.
Liberty is a well-armed sheep contesting the election.
-unknown
They that can give up essential liberty to obtain
a little temporary safety, deserve neither liberty
nor safety.
-Benjamin Franklin
Millions of sniveling cowards shivering in the corner,
begging government to protect them from every threat,
real and imagined,
have stolen liberty from the rest of us.
A government drunk with power, gleefully complies.
-David Kachel
...(paraphrasing Benjamin Franklin)
[9/12] from: holger:rebol at: 15-Aug-2001 12:14
On Wed, Aug 15, 2001 at 11:48:51AM -0600, David Kachel wrote:
> What we are talking about is NOT a minor feature. If *nix platforms had
> no command line, you would implement the needed connections in whatever
> way required.
Software development requires people, money, time and other resources,
all of which are usually scarce. This means platforms and features have
to be prioritized. The market share is one criteria for determining priorities,
but not the only one. The amount of effort, the learning curve and the quality
of developer documentation are other criteria, and, unfortunately, MacOS has
some deficiencies in these areas. MacOS makes it pretty much impossible to
do "casual development" with only minor adaptations from Windows or Unix, the
way it can be done for BeOS, AmigaOS, Elate, QNX, WinCE etc. Developing a MacOS
application that supports all those various MacOS oddities requires a very
focused and resource-consuming development effort for that single platform,
and at the moment we do not always have those resources. We just spent a lot
of time this spring porting View/Pro to MacOS, but there are limits to the
amount of resources we can commit exclusively to a single platform.
As RT grows we will hopefully be able to concentrate more on MacOS, wireless
devices, OS/400, VMS, and some of the other platforms that users frequently
request REBOL ports for. These things take time though.
> Macs do things differently. So what! They require a different kind of
> implementation, i.e., AppleScript. So what! That is the way it is done on
> a Mac. And despite the fact that OS X (*nix based) does have a command
> line, it STILL uses apple events and AppleScript. AppleScript will
> continue to be the way such things are done on the Mac platform, by all
> but the most die-hard.
That is very unlikely. Mac OS X is basically a wrapper around a BSD
(Unix) kernel, that tries to emulate as much of the old Mac OS environment
as possible. Mac OS X supports as much of the legacy Mac OS API (even
Apple calls it "legacy" now) as possible, but internally it is simply yet
another Unix, although with a somewhat fancy desktop. All of the MacOS
legacy functions and features are layered on top of it and around it, i.e.
using those instead of Unix equivalents is possible to some degree, but
probably at a performance penalty compared to using direct Unix APIs.
As far as the execution model of OS X is concerned, that is standard Unix
as well. That's why a normal Unix build of REBOL/Core works just fine on
Mac OS X (with multiple instances, command lines and everything else),
just like the majority of other stdio-based Unix software.
REBOL/View would work as well if OS X supported X11. Without it we would have
to go through Apple's new OO API (Aqua etc.), which we would be happy to do if
Apple could finally get around to providing just a little bit of developer
documentation. Last time I checked the web site still listed pretty much
every single function and concept with the comment "documentation forthcoming"...
> Your complaint that you haven't made Rebol 'the same' on the Mac because
> 'the Mac is different' is at best weak and certainly leaves Rebol's
> "cross-platform" and "universal" claims ringing quite hollow indeed.
My comment was not meant as a complaint, simply as a description of the facts.
cross-platform
does not mean that every single feature is immediately
available, in all versions of REBOL, and on all platforms. Some things simply
take time, and some features won't be available on some platforms at all.
--
Holger Kruse
[holger--rebol--com]
[10/12] from: ryanc:iesco-dms at: 15-Aug-2001 12:43
David, you must take into REBOL Technologies is no IBM. It is a very small, lean,
company, operating with a bare minimum of resources. I am sure that under the
current high tech financing market, they must only fight battles they can win. I
would expect once investors realize this companies potential, and profits begin to
flow, that we will see thorough support for the Mac, as well as other operating
systems that maybe didn't quite make the initial list.
--Ryan
David Kachel wrote:
> Holger Kruse said:
> >REBOL/View on Mac DOES support opening a script with OpenDocEvent (basically
<<quoted lines omitted: 92>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Ryan Cole
Programmer Analyst
www.iesco-dms.com
707-468-5400
[11/12] from: cyphre:volny:cz at: 16-Aug-2001 9:39
----- Original Message -----
From: "Holger Kruse" <[holger--rebol--com]>
To: <[rebol-list--rebol--com]>
Sent: Wednesday, August 15, 2001 9:14 PM
Subject: [REBOL] Re: help with mail attachment please
...we will hopefully be able to concentrate more on MacOS,...
Holger, don't push it too far! I'm gonna scared ;-)
Cyphre
[12/12] from: g:santilli:tiscalinet:it at: 16-Aug-2001 21:42
Hello David!
On 15-Ago-01, you wrote:
DK> What we are talking about is NOT a minor feature. If *nix
DK> platforms had no command line, you would implement the needed
DK> connections in whatever way required.
Apple just had to support a simple way to pass arguments. (AmigaOS
dos it different too, but it does it BETTER.) It doesn't. As
Holger and Jeff confirmend, getting args is complicated on the Mac.
This does not mean REBOL should not support it. It should. But you
fail to understand that RT is not Microsoft nor Apple. They have
other things in the todo-list and not enough time to do everything
in one day.
So, I'm sure better support on the Mac will come one day. If you
want it to happen NOW, why don't you code some C code that gets
Applescript args and calls main() with the standard argc and argv
parameters? You could donate it to RT and they could include it in
the Mac build.
RT has limited resources, period. Implementing all the things in
the todo list will require time, period. If you can't wait, blame
the MacOS for being stupid, or blame the market for being
senseless. People at RT are doing their best.
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted