Date: Fri, 23 Jan 1998 10:57:50 +0000
From: James Berriman <J.R.Berriman at staffs.ac dot uk>
Subject: Testing
Testing 1,2,3...
Date: Fri, 23 Jan 1998 03:26:28 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Taking off
Hi!
The autoshare-dev list is about the AutoShare admin developing scripts,
process extenders and that kind of stuff. About getting to know the
AppleScript dictionary of the server application better and going beyond
the standard built-in features of the server.
<mailto:autoshare at frutiger.staffs.ac dot uk?body=subscribe%20autoshare-dev>
Here is an initial thought for the autoshare-dev list: which are the ways
to make the following script run faster? Responses on the autoshare-dev
only please :-)
---
tell application "AutoShare"
set beginTime to current date
repeat 10 times
GetRes resID 201 resIndex 1
end repeat
set endTime to current date
end tell
endTime - beginTime
---
Not as innocently looking as one might think...
Date: Fri, 23 Jan 1998 21:01:27 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Processing loops
The initial script was:
---
tell application "AutoShare"
set beginTime to current date
repeat 10 times
GetRes resID 201 resIndex 1
end repeat
set endTime to current date
end tell
endTime - beginTime
---
One of the reasons that it takes as long as 34 seconds (on my Mac) to
complete is that each main processing loop reads only one high-level event
at the most (at the beginning of the loop). One of the tricks to make it go
faster is therefore to temporarily let processing loops do less work.
Checking to see if there is work to be done is work too, so enabling the
non-processing mode disables just that:
---
tell application "AutoShare"
SetStat Options {NonProcessing:true}
set beginTime to current date
repeat 10 times
GetRes resID 201 resIndex 1
end repeat
set endTime to current date
SetStat Options {NonProcessing:false}
end tell
endTime - beginTime
---
The script now takes only 20 seconds to complete.
But that is merely the beginning. Other suggestions?
Date: Sat, 24 Jan 1998 00:58:00 -0500
From: Jonathan Shaw <jls4 at cwru dot edu>
Subject: Re: [AS-Dev] Processing loops
>Checking to see if there is work to be done is work too, so enabling the
>non-processing mode disables just that:
An awesome idea!! However, I tried this with a script I am using with
AutoShare, and it actually slowed it down (very informal testing) by about
6 seconds. Here's what I think...
It's work for the script to tell AutoShare to turn off processing and to
turn it back on. My script simply sends three e-mails using AutoShare's
file mail facility. One e-mail is to the sender of the mail to the script
:) and the other two are letters to AutoShare (containing commands). I did
it this way so the user would see the result of the commands. The letter
describes what their request is about to do.
With the disable processing enabled, it took 30 seconds to complete these
commands. This does not include the time taken by AutoShare to process the
two new e-mails to itself.
Without disabling processing, it required about 24 seconds. This, also, is
only a measure of the time spent between the Tell AutoShare and End tell
lines in the script.
I do agree that disabling the processing would be useful when the number of
iterations of commands send to AutoShare is much higher, as in your example.
-Jonathan {;-)
Visit <http://b62968.cwru.edu/> for a good laugh.
There are 3 kinds of people: Those who make things happen, those who watch
things happen and those who wonder what happened.
Date: Sat, 24 Jan 1998 07:48:07 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Serving in the foreground
Here's another thought: what happens if the server application runs in the
foreground? After all, the general idea is that a Mac application should be
designed to run slower in the background. So let's throw in an "activate":
---
tell application "AutoShare"
activate
set beginTime to current date
repeat 10 times
GetRes resID 201 resIndex 1
end repeat
set endTime to current date
end tell
endTime - beginTime
---
The script's repeat loop now takes only a very humble 3 seconds to
complete! The answer to why it is so sets the setting for the next and most
powerful trick.
Date: Sat, 24 Jan 1998 07:48:25 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Processing loops
At 00:58 -0500 24/1/1998, Jonathan Shaw wrote:
>I do agree that disabling the processing would be useful when the number of
>iterations of commands send to AutoShare is much higher, as in your example.
Yes. As I am timing the repeat loop only and not the entire script, I did't
care about how slow the rest of the script is :-) If the repeat loop value
is, say, 1, then the overhead of what's outside the repeat loop is too high
a price to pay for optimizing what's inside it.
Date: Sun, 25 Jan 1998 16:07:19 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: What makes AutoShare tick
As the general idea is that a Mac application should be designed to run
slower in the background, the AutoShare server applies a background ratio
of 3, which simply means that she is nicer to other applications on the
same Mac by giving them more time and giving herself less time.
Time such as this is measured in ticks (1/60th of a second). The default
for AutoShare foreground processing is 5 ticks, which is fine normally. And
a setting of 5 * 3 = 15 ticks in the background certainly is.
Hogging the CPU is most often a relative term. Configuring the AutoShare
ticks setting to zero maximizes AutoShare's time to herself, but does not
stop the system clock from being updated on the Finder's menu bar. Plus 0 *
3 = still 0.
---
tell application "AutoShare"
set myMisc to GetMisc
set myTicks to Ticks of myMisc
SetMisc Options {Ticks:0}
set beginTime to current date
repeat 10 times
GetRes resID 201 resIndex 1
end repeat
set endTime to current date
SetMisc Options {Ticks:myTicks}
end tell
endTime - beginTime
---
2 seconds :-) And it doesn't matter whether you run AutoShare in the
foreground or in the background. Applying the non-processing trick brings
the reading down to a single second.
Where might all of this come in handy? The Admin, which makes lots of
scripting calls to the server from the time the Admin is started up until
it is shut down. All of the Admin windows pop up much faster this way,
usually at little expense on the server as the Admin time used is limited.
Date: Tue, 24 Feb 1998 21:05:18 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Enumerations in scripting
The last some days have been spent by finally(!) applying enumerations.
SetMisc Options {Log: "Brief"}
as an example is now to be replaced by
SetMisc Options {Log: Brief Log}
The advantage is that a compiled script will reveal an invalid enumerated
property value (perhaps due to a typo) as an immediate syntax error,
whereas a string value is a matter of contents rather than syntax and as
such cannot be detected by the AppleScript language per se.
A total of 15 enumerations including 66 enumerators and 75 enumerator
instances have been changed in the server application. Affected are 4
classes (List Options, Misc Options, Times Options and Filter Options) and
7 commands. The AppleScript dictionary, which is merely the tip of the
iceberg as the code to support it took the most time, illustrates how the
property values are placed along with the property names rather than in the
comments.
The sets of enumerated values in the AppleScript dictionary correspond to
the sets of radio buttons in the Admin, as they both reflect the same
multiple choice situations.
The comments for boolean and enumerated values have been fully updated in
the dictionary to reflect defaults whereever not indicated previously. The
same goes for optional and read-only indicators.
Additionally and extending the above totals, the value for the Lists
parameter in the GetFilters command is now enumerated as well. The Listserv
property in the Folder Options class has been renamed to List Server. The
Listserver Name property in the Misc Options class has been renamed to List
Server Name.
That's it. Now onto updating the Admin and the script samples...
Date: Wed, 25 Feb 1998 12:28:40 +0100
From: Jan Koudelka <koudelka at appleklub dot cz>
Subject: Re: [AS-Dev] Enumerations in scripting
>The last some days have been spent by finally(!) applying enumerations.
> SetMisc Options {Log: "Brief"}
>as an example is now to be replaced by
> SetMisc Options {Log: Brief Log}
Oh no! My Remote Admin strongly benefits on the text parameters. Do you
plan to include some function which will take the original text parameter
and convert it to the new one? Bad parameters can be then converted for
example to some special invalid parameter value.
HOnza
Date: Wed, 25 Feb 1998 22:08:00 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Enumerations in scripting
At 12:28 +0100 25/2/1998, Jan Koudelka wrote:
>Oh no! My Remote Admin strongly benefits on the text parameters.
It is a lot easier than you may think! If you have a string defined as
set kBriefLog to "Brief"
you would now have it defined as simply
set kBriefLog to Brief Log
as long as you put the tell application wrapper around it.
Apart from being basically the same, the added advantage is that you do not
have to specify the contents of the text parameter strings anymore :-)
There are only 51 text parameter strings, not 66 as stated previously (I
had accidently included the 15 properties in the count); they have been
used for doing the Admin this evening:
tell application "AutoShare"
set kSubscriptionList to Subscription List
set kOpenList to Open List
set kModeratedList to Moderated List
set kAnnouncementList to Announcement List
set kPrivateList to Private List
set kDefaultList to Default List
set kListReplyTo to List ReplyTo
set kSenderReplyTo to Sender ReplyTo
set kConfigurableReplyTo to Configurable ReplyTo
set kDefaultReplyTo to Default ReplyTo
set kShowNames to Show Names
set kSuppressNames to Suppress Names
set kDefaultNames to Default Names
set kYes to Yes
set kNo to No
set kDefault to Default
set kOffLog to Off Log
set kAlwaysLog to Always Log
set kBriefLog to Brief Log
set kTechLog to Tech Log
set kTextFormat to Text Format
set kHTMLFormat to HTML Format
set kBothFormats to Both Formats
set kOffBounces to Off Bounces
set kOnBounces to On Bounces
set kEmptyBounces to Empty Bounces
set kBodyCommands to Body Commands
set kSubjectCommands to Subject Commands
set kUnsorted to Unsorted
set kDomainSort to Domain Sort
set kUserSort to User Sort
set kNoTime to No Time
set kAllTimes to All Times
set kMessageTime to Message Time
set kLogTime to Log Time
set kTextPlain to Text Plain
set kMimeQP to Mime QP
set kQPAlways to QP Always
set kComplete to Complete
set kMinimal to Minimal
set kAlwaysSuppress to Always Suppress
set kNeverSuppress to Never Suppress
set kBodySuppress to Body Suppress
set kLogFile to Log File
set kDigestFile to Digest File
set kNoPrefix to No Prefix
set kFromPrefix to From Prefix
set kToPrefix to To Prefix
set kSubjectsPrefix to Subjects Prefix
set kReplyToPrefix to ReplyTo Prefix
set kSenderPrefix to Sender Prefix
end tell
Date: Thu, 26 Feb 1998 16:37:07 +0100
From: Jan Koudelka <koudelka at appleklub dot cz>
Subject: Re: [AS-Dev] Enumerations in scripting
>At 12:28 +0100 25/2/1998, Jan Koudelka wrote:
>
>>Oh no! My Remote Admin strongly benefits on the text parameters.
>
>It is a lot easier than you may think! If you have a string defined as
> set kBriefLog to "Brief"
>you would now have it defined as simply
> set kBriefLog to Brief Log
>as long as you put the tell application wrapper around it.
Yes, but the CGI gets ONLY string parameters from HTTP forms.
HOnza
Date: Thu, 26 Feb 1998 19:55:55 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Enumerations in scripting
At 16:37 +0100 26/2/1998, Jan Koudelka wrote:
>Yes, but the CGI gets ONLY string parameters from HTTP forms.
You are asking for trouble by assigning the CGI parameter to the dual role
of being an HTTP form value and an AppleScript property value. Some may
even argue that the value being a CGI parameter is a third role :-)
It is my recommendation that translation take place within the CGI.
Something like: if a given CGI parameter, then apply the corresponding
property value. It is a bit more work, but it is by far the cleanest way to
go.
Date: Fri, 27 Feb 1998 09:53:11 +0100
From: Jan Koudelka <koudelka at appleklub dot cz>
Subject: Re: [AS-Dev] Enumerations in scripting
>It is my recommendation that translation take place within the CGI.
>Something like: if a given CGI parameter, then apply the corresponding
>property value. It is a bit more work, but it is by far the cleanest way to
>go.
Probably cleanest, but not fastest, if the CGI is written in AppleScript.
Every if-then command conversion if performed as compiled additional
conversion function would be much faster. And having this conversion
function is much cleaner than having it, for example, in an OSAX.
But, this is still only idea, not a request.
HOnza
Date: Sun, 1 Mar 1998 13:18:49 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Enumerations in scripting
At 09:53 +0100 27/2/1998, Jan Koudelka wrote:
>Probably cleanest, but not fastest, if the CGI is written in AppleScript.
Well, that's AppleScript for you :-)
How do you deal with boolean parameters and properties btw?
Date: Wed, 4 Mar 1998 23:00:22 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Script activating process extender
I asked myself this question: how can support for the EIMS 2.1b1 New
Account AppleScript command best be incorporated into the AutoShare Admin?
The preliminary thought came to me quickly: not directly anyway. Placing
the actual New Account in the Admin would bring up the various headaches of
the overhead of the Admin running remotely. And as the New Account command
is fairly new, it may not have reached its final form, so a new Admin would
have to made every time a change was made to that command. The issue of
flexibility also surfaced.
The answer was to let the AutoShare server application call the EIMS
server, as they usually reside on the same Macintosh. An Admin script
snippet would call AutoShare, which passes some parameters onto a process
extender dealing with EIMS directly.
Here is how the Admin would call AutoShare:
tell application "AutoShare"
RunScript scriptList "Fun-L" scriptIndex 1
end tell
AutoShare receives the two parameters, and because the script command is
RunScript, she passes these two parameters onto a process extender called
Script, which says: "OK, I have the name of a list, and the index
determines what kind of action I'll take. If the index is 1, then my script
has a snippet for creating the needed EIMS accounts for a new AutoShare
list. And I'm a flexible kind of guy, because my script can be written any
which way I desire!".
on idle
return 300
end idle
on «event AuSCaUSC» (aList)
set kList to item 9 of aList
set kScriptType to item 10 of aList
if kScriptType = 1 then
tell application "EIMS Server"
-- create EIMS accounts here using kList
end tell
end if
end «event AuSCaUSC»
The EIMS calls can replaced with SIMS calls or any other
application-specific calls. Or simply whatever. And within a given index.
What do you think?
Date: Fri, 6 Mar 1998 11:12:02 +0100
From: Jan Koudelka <koudelka at appleklub dot cz>
Subject: Re: [AS-Dev] Script activating process extender
>on <event AuSCaUSC> (aList)
> set kList to item 9 of aList
> set kScriptType to item 10 of aList
>
> if kScriptType = 1 then
> tell application "EIMS Server"
> -- create EIMS accounts here using kList
> end tell
> end if
>end <event AuSCaUSC>
>
>The EIMS calls can replaced with SIMS calls or any other
>application-specific calls. Or simply whatever. And within a given index.
>
>What do you think?
And what about this (it would be nice to see the following words in the
AutoShare 2.3 Documentation):
When the SetList command is used with a list name that does not exist,
AutoShare will create all necessary files (I mean the list file). It will
also look if it is using EIMS 2.1 or newer, and if it is true, it will also
create all necessary e-mail accounts and configure them correctly depending
on the AutoShare settings.
It is more work on AS development, but it would be more stable, faster, and
also nicer solution.
HOnza
Date: Fri, 6 Mar 1998 22:22:47 -0800
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Script activating process extender
At 11:12 +0100 6/3/1998, Jan Koudelka wrote:
>And what about this (it would be nice to see the following words in the
>AutoShare 2.3 Documentation):
But first I must release 2.2 :-)
>When the SetList command is used with a list name that does not exist,
>AutoShare will create all necessary files (I mean the list file). It will
>also look if it is using EIMS 2.1 or newer, and if it is true, it will also
>create all necessary e-mail accounts and configure them correctly depending
>on the AutoShare settings.
>
>It is more work on AS development, but it would be more stable, faster, and
>also nicer solution.
Well yes. It is just that I cannot do this until the needed account
scriptability is final in EIMS (and SIMS), which it is not.
Date: Mon, 9 Mar 1998 12:28:10 +0100
From: Jan Koudelka <koudelka at appleklub dot cz>
Subject: Re: [AS-Dev] Script activating process extender
>At 11:12 +0100 6/3/1998, Jan Koudelka wrote:
>
>>And what about this (it would be nice to see the following words in the
>>AutoShare 2.3 Documentation):
>
>But first I must release 2.2 :-)
I believe that you are creating a plan of 2.3 features (of those they will
not be in 2.2) while finishing the 2.2 release... :-)
>Well yes. It is just that I cannot do this until the needed account
>scriptability is final in EIMS (and SIMS), which it is not.
Of course. That's why I was talking about version 2.3 :-)
HOnza
Subject: Maybe a dumb question
Date: Fri, 15 May 1998 21:57:44 -0400
From: Eric Mings <elm at ao dot net>
I posted this previously to the regular Autoshare talk list and Mikael
suggested we discuss it on this list. I already have a "remove" database
with one record per email address that might be useful for setting the
addresses that should not receive a mail back. Here is my original
question:
I wonder if there is a way to have Autoshare compare the from: address
to a daemon list prior to performing the mailback task. Here is my
concern. A while back, Mikael provided me much help in setting up
autoshare such that I can use it to confirm membership requests that are
entered into filemaker via a web form. The simple overview is this:
1 Person fills out form on webpage
2 Filemaker sends a message using the email address entered in the form
to the autoshare mailback account.
3. Autoshare sends the confirmation request back to that address.
4. The person replies with the code and a processor enters their email
into a related database that I setup for confirmation.
This all works flawlessly!
My purpose for all this is to assure that no one can fraudulently enter
someone else into my membership database and subject them to mailings I
send that they wouldn't want. The only thing I cannot accomplish with
this setup is preventing someone from repeatedly entering someone elses
mail address in my database, and them subsequently receiving the
(unwanted) mailback confirmation. Once someone contacts me to let me know
that there has been an fraudulent attempt to subscribe them by someone
else, I would like to prevent them from receiving the mailback
confirmation in the future -if the rascal tried it again. I have already
taken other measures to deal with trouble makers by automatically logging
the IP number and time of submission with each membership record created
so I can track and complain to their ISP if necessary. Although this may
sound like overkill to some, I beleive it is necessary to protect the
integrity of my business and avoid "blacklisting" of my domain for my
legitimate bulk emails. Any ideas _greatly_ appreciated. Thanks.
Regards,
Eric Mings Ph.D.
Date: Fri, 15 May 1998 23:46:01 -0400
From: Jonathan Shaw <jls4 at cwru dot edu>
Subject: Re: [AS-Dev] Maybe a dumb question
>My purpose for all this is to assure that no one can fraudulently enter
>someone else into my membership database and subject them to mailings I
>send that they wouldn't want. The only thing I cannot accomplish with
>this setup is preventing someone from repeatedly entering someone elses
>mail address in my database, and them subsequently receiving the
>(unwanted) mailback confirmation. Once someone contacts me to let me know
>that there has been an fraudulent attempt to subscribe them by someone
>else, I would like to prevent them from receiving the mailback
>confirmation in the future -if the rascal tried it again. I have already
>taken other measures to deal with trouble makers by automatically logging
>the IP number and time of submission with each membership record created
>so I can track and complain to their ISP if necessary. Although this may
>sound like overkill to some, I beleive it is necessary to protect the
>integrity of my business and avoid "blacklisting" of my domain for my
>legitimate bulk emails. Any ideas _greatly_ appreciated. Thanks.
For some reason, this sounds like a task for FileMaker Pro, not AutoShare.
In FMP, you can set the e-mail address field to not allow duplicate values
(validation->unique). So, when a user fills out a web form and the form is
submitted to FMP, it will attempt to add a record for that form's
information. If the record remains from a previous attempt to subscribe,
then it shouldn't be able to add the record, again. The processor that
enters their e-mail address after confirmation should also remove the
original record from the first database (the one that starts the whole
process). If a subscription request is NOT confirmed, then the original
record will still exist, and further subscription attempts will be blocked
before a confirmation letter is mailed out.
By the way, my brother (eric at ao dot net) used to work (basically volunteer?)
for Access Orlando (and he may still?)... didn't realize you guys use Macs!
That's pretty cool.
-Jonathan {;-)
Visit <http://b62968.cwru.edu/> for a good laugh.
There are 3 kinds of people: Those who make things happen, those who watch
things happen and those who wonder what happened.
Date: Sun, 17 May 1998 19:58:25 -0700
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Maybe a dumb question
At 21:57 -0400 15/5/1998, Eric Mings wrote:
>I already have a "remove" database with one record per email address
>that might be useful for setting the addresses that should not receive
>a mail back.
At 23:46 -0400 15/5/1998, Jonathan Shaw wrote:
>For some reason, this sounds like a task for FileMaker Pro, not AutoShare.
For both and for the process extender. FileMaker Pro can't apply a kill
filter to suppress additional mail-back messages, but is able to determine
if an address already appears in a record and so can pass the result being
the suppress status back to the process extender, which passes it back to
AutoShare, which suppresses the actual message. The above database is
nothing more than a filter file really, but I suspect that it'll work quite
well.
Having process extenders communicate with scriptable database software such
as FileMaker Pro is a very interesting topic. It is important to me that
process extenders have brief standardized code, be easy to write and come
across as little a bottleneck as possible. When that is said, I was
wondering how you would like this communication to be put to further use in
future.
Subject: Re: [AS-Dev] Maybe a dumb question
Date: Sun, 17 May 1998 23:38:20 -0400
From: Eric Mings <elm at ao dot net>
In the ongoing discussion we left off at:
>>For some reason, this sounds like a task for FileMaker Pro, not AutoShare.
>
>For both and for the process extender. FileMaker Pro can't apply a kill
>filter to suppress additional mail-back messages, but is able to determine
>if an address already appears in a record and so can pass the result being
>the suppress status back to the process extender, which passes it back to
>AutoShare, which suppresses the actual message. The above database is
>nothing more than a filter file really, but I suspect that it'll work quite
>well.
>
>Having process extenders communicate with scriptable database software such
>as FileMaker Pro is a very interesting topic. It is important to me that
>process extenders have brief standardized code, be easy to write and come
>across as little a bottleneck as possible. When that is said, I was
>wondering how you would like this communication to be put to further use in
>future.
Well after getting Jonathan's suggestion, I felt a little dense. Indeed,
the simple route of verify uniqueness in the email address field of my
main database in FMP solves many problems quite effectively. Because I
have Filemaker setup to send the initial email to EIMS/Autoshare when a
record is created, this stops the problem before the mail is ever sent to
EIMS/Autoshare. The only downside is that I have to keep "dead" records
in the datbase to assure this doesn't happen. The upside is it also
prohibits the problem of duplicate records, and forces members to edit
their existing record rather than creating new ones.
That being solved, I still think that a database "filter file" of some
type to inhibit (or conversely allow) simple autoreply or mailback
messages from Autoshare could be of great use. In the "allow" situation
for example, I could provide some valuable info by autoreply, but only to
"members" that were in my database. Actually, the more I think about it,
the more useful that idea becomes if it doesn't require too much
processor overhead. Thanks for the help!
P.S. to Jonathan:
Access Orlando does not use Macs to my knowledge, they just happen to be
the ISP that I am using. However, I am quite pleased with their service
and may investigate the possibility of colocation of one of my Macs with
them in the foreseeable future. I am almost certainly going to go the
colocation route in the next few months if things go well
(recommendations off the list are welcome).
Regards,
Eric Mings Ph.D.
Date: Sun, 17 May 1998 23:25:29 -0700
From: Mikael Hansen <meh at dnai dot com>
Subject: Re: [AS-Dev] Maybe a dumb question
At 23:38 -0400 17/5/1998, Eric Mings wrote:
>Because I have Filemaker setup to send the initial email to
>EIMS/Autoshare when a record is created, this stops the problem
>before the mail is ever sent to EIMS/Autoshare.
I don't quite understand this. What am I missing?
Subject: Re: [AS-Dev] Maybe a dumb question
Date: Mon, 18 May 1998 08:47:31 -0400
From: Eric Mings <elm at ao dot net>
>>Because I have Filemaker setup to send the initial email to
>>EIMS/Autoshare when a record is created, this stops the problem
>>before the mail is ever sent to EIMS/Autoshare.
>
>I don't quite understand this. What am I missing?
With FMP 4 web companion you can set it up to send email when a record
is added via a web form. I have the form setup to send the email to the
EIMS account when the form is successfully processed and the record
added, using the "from" address that the person enters in the form. That
then kicks in the whole EIMS/Autoshare mailback thing to confirm that the
"from" address was actually correct, and when the mailback is
successfully completed a record is added to a related "confirmed"
database. There is no possible way to stop someone from forging an email
address in the form the first time (and producing an unwanted mailback to
that address), but the address is never in my confirmed database so I
don't send them any more mail. As long as I leave that "dead" record in
my main database Filemaker will not add a duplicate (the unique
validation option on the address field) and thus will not send mail to
trigger another mailback.
Regards,
Eric Mings Ph.D.
Date: Mon, 18 May 1998 22:48:45 -0400
From: Jonathan Shaw <jls4 at cwru dot edu>
Subject: Re: [AS-Dev] Maybe a dumb question
>Well after getting Jonathan's suggestion, I felt a little dense. Indeed,
>the simple route of verify uniqueness in the email address field of my
>main database in FMP solves many problems quite effectively. Because I
>have Filemaker setup to send the initial email to EIMS/Autoshare when a
>record is created, this stops the problem before the mail is ever sent to
>EIMS/Autoshare. The only downside is that I have to keep "dead" records
>in the datbase to assure this doesn't happen. The upside is it also
>prohibits the problem of duplicate records, and forces members to edit
>their existing record rather than creating new ones.
Please don't feel dense. I'm sure you could help me with other stuff in
FMP! :) As far as you wasting space on "dead" records--you're not, really.
I mean, you need to track the addresses somehow if you don't want spammers
to take advantage of people. Now, you may be storing lots of extra bytes
due to the other fields in each record. There are ways to solve this, most
notably by taking advantage of the relational features of FMP. But, it is
most likely not worth the extra trouble, as it may make dealing with your
_real_ subscribers that much more cumbersome. FMP and other databases take
great effort to store information efficiently, with quick access, etc. It
will probably not increase your file size by too much to track those extra
people.
>That being solved, I still think that a database "filter file" of some
>type to inhibit (or conversely allow) simple autoreply or mailback
>messages from Autoshare could be of great use.
That does seem like a cool idea. I don't see where I would use it myself,
but I can see how it might be very useful to others. A good example: a
shareware author would like approved beta testers to receive updates via a
auto-responder. Another: a teacher makes test solutions available to
students in her class.
-Jonathan {;-)
Visit <http://b62968.cwru.edu/> for a good laugh.
There are 3 kinds of people: Those who make things happen, those who watch
things happen and those who wonder what happened.