cogole@gmail.

com
To:cogole@gmail.com,faridalubanga@gmail.com,rehemaapio@gmail.com,pullepatrick@yahoo
.co.uk,florenceaworacol@yahoo.com
Jun 4, 2016 at 8:26 PM

Received at 8:26:09 PM EDT on 6 ***** This is a test signal. For testing purposes, it is being
sent out every day. When the test is complete over the next day (May 2016) or so, the
notifications will be sent out regularly - only once a week! Quota remaining for today= 100

An algorithm for maximizing automatic email message dissemination from Google mail
service, applied to sending out the LAONA memorabilia++ - so to speak on (ir)regular basis

Background

We have a rich repository of data, information, knowledge or wisdom gathered from as far back as 2004
up to today (June 3 2016). The knowledge base is completely original, and the content of the discourse
covers just about everything we encounter in our everyday lives. We may thus regard our repository as a
universe of discourse, of sort. Yet these repository resources need to be made readily available to
potential users any time they need it. One way of realizing this seamless of information is through
regular email notifications.

The technical challenge is that Google mail service which would be ideal (for me) to use- since most
potential recipients of the notifications in question are already accustomed to receiving my Google
email address imposes some constraints on the use of mail service. Consider sending emails from a
gmail account from a script (that is, automatically). The maximum number of email recipients that can
be sent (in the TO, CC and BCC, all combined) from the email account on a given day (24-hour period) is
100. The maximum number of recipients per email message is 50. What this means is that if we have
100 email addresses on the recipient list, a script can only accept 50 per message sent. So we have to
partition the 100 email elements into two, and send the two emails separately- one after the other. The
execution time for the script (which a user has to write) must not exceed 6 minutes per session (of
sending a message). The number of times the time trigger is fired (invoked) to send a message is also
limited per second, per day, etc.

Now, consider a problem where we have not only 100 people on the list but 500+ as in the Lango list.
Our script has to keep partitioning the 500 elements into smaller groups of 50 or less and send an email
to each partition keeping in mind some of the constraints noted above. That’s what our code does!

The magic code 1237+ LOC

The code sends email notifications reminding members on the predefined list (Lango community list of
500+ people) on regular intervals of our knowledge repository (memorabilia++).

Every day, an email is sent to 100 people- in two batches, each of size 50.
Handling time constraint

On a given day, within a specified time (hour, minutes) of the day, two emails are sent to the members
on the two batches, in succession (e.g. of about 1 minute) in one trigger.

Selection of batch constituents

e1 e2 e3 e4 e5 e6 e7 e8
e9 e10 e11 e10 e11 e12 e13 e14
e15 e16 e17 e18 e19 e20 e21 e22
e23 e24 e25 e26 e27 e28 e29 e30

From a pool of string elements (email addresses), select 45 elements such snew= P-S.

Index of e12 is determined using the function

getNextBeginningCharacterPosition(….)

index of e30 is determined by the batch size – which is a parameter to the getNextBeginningCharacter
position

S= e12 e22 e26 e30

Once S is retrieved from persistent storage, that record (row) in the sent data is replaced by snew

= e3 e16 e18 e27