Need JavaCompanion update

Re: Need JavaCompanion update

From:

Date:

Time:

on 2/1/01 0:23, Bill Pickering at wpicker@earthlink.net wrote:

> Hi Wayne,
>
> Thanks for your prompt reply.
>
>>> 2) I like the fact that MondoMail Daemon manages queue of outgoing email
>>> separately from FileMaker. How does this separation benefit compare when
>>> using JavaCompanion?
>
>> In simple terms, FMP will have to remain open until the messages finish
>> being transferred to the mail server. On the plus side, my tests indicate
>> each individual message is generally transferred much faster than with the
>> current Daemon set-up. Plus, you can configure it to messages in the
>> background (but within FM's application context), and send multiple messages
>> simultaneously.
>
> Multiple messages (hmm...) Is that like multiple CC: or BCC: of the same
> message to individual recipients? OR entirely separate multiple messages?

In general, multiple messages. If you simply use multiple recipients on a
single message, that is delivered as a single message. Although... in
reality, if you have more than 100 recipients, it is supposed to be
transferred to the mail server as separate messages with no more than 100
messages. The current mondomail does this (as required by the SMTP RFC), but
I haven't confirmed that the latest does things that way (though I just
wrote to them to ask about this; in any case, don't worry about this little
issue, it will be handled correctly one way or another).

>> One of the options to (the current JC MondoMail) is a send timeout. When the
>> message cannot be passed to the server before the timeout is exceeded,
>> control is returned to FM. So in practice, you can set a timeout of zero,
>> and the message is simply sent in the background (again, within FM's
>> context, not in a separate application). A preference controls the max
>> number of background threads, and whenever this maximum is reached, JC/MM
>> will wait until the number of threads drops below a certain threshold (thus
>> freeing up multiple new thread slots), before starting the next thread and
>> returning to FM.
>
> Multiple threads; like a queue? Background activity in context of same
> (FM) application is difficult to understand. Is there actually a
> precedence between FileMaker and JC? Does JC hold up FileMaker processing
> after, say 10 threads exceeded?

Not a queue, in that that implies one-at-a-time processing. Rather, multiple
threads are spawned and each attempts to deliver the message to the mail
server simultaneously.

JC will not return control to FileMaker until either the message is passed
off to the mail server, or the timeout value you specify is exceeded. In the
latter case, the thread continues to deliver the message during idle time
given to JC from FileMaker. [FM plugins can request that FM give them idle
time slices when nothing else is going on inside FM.]

>> A future version might offer a detached sending agent, but I'll need to run
>> more tests to see if the speed increase would warrant the work.
>
> Interesting. Either way somehow must manage a queue of events and control
> stream of messages passed to mail host.
>
>> There were at least a couple of logging mechanisms. Which type of logging
>> did you rely on? The current JC/MM does create a separate mail log with
>> parsable entries...
>> And somewhere I have a FM database that you can import these entries to.
>
> Yes, I found a database "Mail Log Importer.fp3" in the Demos folder. This
> should suffice. Otherwise I have a secure remote site mgmt tool that lets
> me view select portions of any text file on the server via web browser.

Yes, it at least has that much logging.

>>> 4) I especially like the error notification capability of MondoMail. Is
>>> there any error notification using JavaCompanion? (Critical need for
>>> support of active solution).
>>
>> What type of notification was that?? Describe what you mean please.
>
> I was referring to the portion of the MondoMail/FM 1.1 Plug-in (using
> "MondoMail/FM Settings" database) which sets the parameters in the
> AppleScript file for forwarding daily log to specified email address,
> also toggles whether to send email error notification to admin (me in
> this case). This gives me warning when there are problems with massive
> amounts of pending mail in the "Outgoing" messages folder. This happened
> once when a router failed and mail host was inaccessible. I was able to
> contact hosting service and have the problem quickly resolved; then
> monitored as MondoMail Daemon gradually sent pending mail to mail host. I
> now understand that Java App in JavaCompanion is handling this process
> instead of AppleScript. I just wanted to know if there is any way for JC
> to automate sending me an error message as part of the email process. I
> currently receive MondoMail error messages whenever a user submits via
> web to FileMaker and screws up their email address, or when I receive any
> one of the MondoMail error codes. I can't do much about inept/careless
> users, but I can usually respond to (numerous) error messages warning of
> undeliverable conditions. Fortunately, most of the time everything in
> current server is stable, which means low maintenance.

Yes, something similar to that can be added. But of course, if no mail can
get out, then neither can messages to the administrator. I might look at a
kind of notification extension mechanism, then provide a few options such as
hitting a web page (e.g., for paging someone), emailing an administrator,
etc.

>> Would you be sending mail from the same copy of FMP which is handling the
>> web requests? There could be some implications for performance if so.
>
> Yes for now. In my current configuration, I have only one server, and it
> adequately handles incoming FileMaker records received from the web.
> MondoMail then sends the submitter a brief thank you email message as
> part of the process. I retain only the MondoMail result (MM...). In the
> future, I would consider an entirely separate server dedicated to sending
> bulk email. I don't know if FileMaker will become an permanent integral
> part of that bulk process, but it would make sense to use a database to
> select records for target bulk email recipients. In that case we probably
> wouldn't care about individual bad email addresses, but we'd be more
> concerned about server problems in general.
>
> My main objective now is to find an adequate email solution that won't
> tax an existing web-enabled FileMaker Pro server. Emails are
> automatically sent to the submitter using MondoMail/FM. My client thinks
> he's falling behind the times because he's unable to send colorful HTML
> content. We are handling up to 4-5 records per minute (not a heavy
> volume). I'm confident JC can provide this thread capacity.

Oh yeah, if all you're doing is sending out some messages in response to web
requests, shouldn't be a big deal.

> I want to take things a little further with JavaCompanion. In our current
> online solution, a new record is received via web form submit. Upon
> receipt in FileMaker, we are now sending a thank you email to the
> submitter plus additional merge email messages to (up to 3) referral
> people. The merge message contains a URL link taking them to our site to
> -- you guessed it -- sign up (guestbook). It's a voluntary legitimate
> marketing scheme. My challenge is to include (import) a HTML form right
> into a multipart message. Both text and HTML portions of the message
> would contain merged content. This would allow me to 'preload' hidden
> elements of the web form with key merge information. Text-only email
> readers would still need to follow the embedded web link to access the
> form online, but that's already working fine. I hope this makes some
> sense. More than that, I hope I can somehow accomplish this feat. At this
> point, I'm fully open to feedback/comments.

Sounds cool, but I'm not sure that Mac mail clients can deal with html forms
inside the mail client. Outlook on Windows probably could since I suspect it
just uses the IE html engine.

>> I'll get you out the latest files today or tomorrow. Just remind me if for
>> some reason you don't receive them by then.
>
> Files?? I look forward to receiving them to begin my testing. If you're
> ready to sell licensed copies JavaCompanion (I don't need POP3), please
> send me a (MondoMail/FM 1.1) upgrade price quote. My client is
> "impatiently" waiting for HTML-compatible mail solution.

OK, will package up as soon as I send this off to you.

The upgrade is currently $25 per copy. Volume upgrade pricing is possible.

> Thanks again for your feedback,
>
> Bill Pickering
>
> Evergreen, CO
> FileMaker Pro/Web site developer
> Member: Association of Database Developers
> Member: FileMaker User Group (Metro Denver)

-wayne
--
Acme Technologies
http://www.acmetech.com

-------------------------------------------------------
To subscribe, unsubscribe and list archive please visit
http://www.digitalpoint.com/lists/javacompanion.html
-------------------------------------------------------

Sales:
888/4-DPOINT

Support:
858/452-3696