Threading water.

[Soren Bro]

It may look like I'm doing nothing but believe me I'm in the fray - like my
ultimate idol Jean Parisot de Valette
https://en.wikipedia.org/wiki/Jean_Parisot_de_Valette, The Christian
Commander from The Siege of Malta in 1540. This guy slaughtered hordes of
oncoming enemies (they happened to be muslims, but that's ofcourse not
important, cough) with a two-handed sword I probably wouldn't be able to
lift, wearing full battle armor at the age of 70!!

I know you guys hate the underlying database idea, so I'm working both
ways. My SQL is a little rusty though. Give me a little time. A week or so
to blind you with science.... I'll get my science gun out.. (
http://amultiverse.com/tag/science-guns/)....

Sending and receving email should be fairly easy having the Eudora DLLs and
LIBs, so I´m investing a little time with the SQL way. And yes, I know you
hate me for it. On the other hand I work for free and there's no such thing
as a free lunch.... So what you see is what you get.

And to be brutally honest you haven´t seen much, Hmm....

This is a part of where I´m at with SQL, but it's a tiny part...Also, I'm
sure mysql is able to send emails. We just need to make it pretty. and THAT
at least I think I have shown I can do.

I'm further than this, but this was what was open in my textpad client...

Regards.

-- Start over.
DROP DATABASE HERMES;
CREATE DATABASE HERMES;
USE HERMES;

-- Create normalization and internal tables. If you find yourself forced to
maniplate one of these manually you're doing something wrong!
-- The '_' in front of names should be a giveaway. It basically means
"don't touch me". Use the proper Stored Procedures instead.
DROP TABLE _NAMES;
CREATE TABLE _NAMES (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, NAME
VARCHAR(50) NOT NULL UNIQUE);
DROP TABLE _NICKS;
CREATE TABLE _NICKS (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, NAME
VARCHAR(50) NOT NULL UNIQUE);
DROP TABLE _SERVERS;
CREATE TABLE _SERVERS (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, SERVER
VARCHAR(50) NOT NULL UNIQUE);
DROP TABLE _NETS;
CREATE TABLE _NETS (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, NET
VARCHAR(50) NOT NULL UNIQUE);

-- Even this isn't supposed to be manipulated directly. There will be views
and, again, Stored Procedures for that.
DROP TABLE _CONTACTS;
CREATE TABLE _CONTACTS ( \ ID INT NOT NULL PRIMARY KEY, \ NAME1_ID INT, FOREIGN KEY (NAME1_ID) REFERENCES _NAMES(ID), \ NAME2_ID INT, FOREIGN KEY (NAME2_ID) REFERENCES _NAMES(ID), \ NAME3_ID INT, FOREIGN KEY (NAME3_ID) REFERENCES _NAMES(ID), \ NICK_ID INT, FOREIGN KEY (NICK_ID) REFERENCES _NICKS(ID), \ SERVER_ID INT, FOREIGN KEY (SERVER_ID) REFERENCES _SERVERS(ID), \ NET_ID INT, FOREIGN KEY (NET_ID) REFERENCES _NETS(ID) \ );

DROP PROCEDURE AddContact;
DELIMITER //
CREATE PROCEDURE AddContact(IN EMAIL VARCHAR(50))
BEGIN
DECLARE WORK VARCHAR(50);
SELECT TRIM(EMAIL) INTO WORK;

SELECT WORK;
SELECT SUBSTRING_INDEX(WORK, '@', 1);
SELECT SUBSTRING_INDEX(WORK, '@', -1);
SELECT SUBSTRING_INDEX(WORK', '.', -1);

END //
DELIMITER ;

CALL AddContact(' sbrothy@gmail.com ');

DROP PROCEDURE AddContact;
DELIMITER //
CREATE PROCEDURE AddContact (IN EMAIL VARCHAR(50))
BEGIN
DECLARE WORK VARCHAR(50);

SELECT TRIM(EMAIL) INTO WORK;

SELECT WORK;

SELECT SUBSTRING_INDEX(WORK, '@', 1);
SELECT SUBSTRING_INDEX(WORK, '@', -1);
SELECT SUBSTRING_INDEX(WORK, '.', 1);
SELECT SUBSTRING_INDEX(WORK', '.', -1);

END
//
DELIMITER ;

CALL AddContact('sbrothy@gmail.com');

---

SELECT SUBSTRING_INDEX(TEMAIL, '@', 1) INTO NICK;
SELECT SUBSTRING_INDEX(TEMAIL, '@', -1) INTO WORK;
SELECT SUBSTRING_INDEX(WORK, '.', 1) INTO SERVER;
SELECT SUBSTRING_INDEX(WORK', '.', -1) INTO NET;

SELECT NICK;
SELECT WORK;
SELECT SERVER;
SELECT NET;

SELECT ID FROM _NICKS WHERE NICK = @NICK INTO @NICK_ID;
IF(@NICK_ID IS NULL)
THEN
INSERT INTO _NICKS VALUES(ID, NAME) (NULL, @NICK);
SELECT LAST_INSERT_ID() INTO @NICK_ID;
END IF;

SELECT ID FROM _SERVERS WHERE SERVER = @SERVER INTO @SERVER_ID;
IF(@SERVER_ID IS NULL)
THEN
INSERT INTO _SERVERS VALUES(ID, SERVER) (NULL, @SERVER);
SELECT LAST_INSERT_ID() INTO @SERVER_ID;
END IF;

SELECT ID FROM _NETS WHERE NET = @NET INTO @NET_ID;
IF(@NET_ID IS NULL)
THEN
INSERT INTO _NETS VALUES(ID, NETS) (NULL, @NET);
SELECT LAST_INSERT_ID() INTO @NET_ID;
END IF;

INSERT INTO _CONTACTS VALUES(ID, NAM1E_ID, NAME2_ID, NAME3_ID, NICK_ID,
SERVER_ID, NET_ID) (NULL, NULL, NULL, NULL, @NICK_ID, @SERVER_ID, @NET_ID);

CREATE TABLE _MESSAGES ( \ ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, \ RECEIVERS BLOB, \ BCCS BLOB, \ CCS BLOB \ );

---

DROP PROCEDURE AddContact;
DELIMITER //
CREATE PROCEDURE AddContact (IN EMAIL VARCHAR(50))
BEGIN
DECLARE 'WORK' VARCHAR(50);
DECLARE 'TEMAIL' VARCHAR(50);
DECLARE 'NICK' VARCHAR(50);
DECLARE 'NICK_ID' INT DEFAULT NULL;
DECLARE 'SERVER' VARCHAR(50);
DECLARE 'SERVER_ID' INT DEFAULT NULL;
DECLARE 'NET' VARCHAR(50);'
DECLARE 'NET_ID' INT DEFAULT NULL;'

DECLARE 'NAME1_ID' INT DEFAULT NULL;
DECLARE 'NAME2_ID' INT DEFAULT NULL;
DECLARE 'NAME3_ID' INT DEFAULT NULL;

SELECT TRIM('EMAIL') INTO 'TEMAIL';

SELECT 'TEMAIL';

SELECT SUBSTRING_INDEX('TEMAIL', '@', 1) INTO 'NICK';

SELECT 'NICK';

SELECT SUBSTRING_INDEX('TEMAIL', '@', -1) INTO 'WORK';

SELECT 'WORK';

SELECT SUBSTRING_INDEX('WORK', '.', 1) INTO 'SERVER';

'SELECT 'SERVER;

SELECT SUBSTRING_INDEX(@WORK', '.', -1) INTO NET;

SELECT NET;

SELECT ID FROM _NICKS WHERE NICK = 'NICK' INTO NICK_ID;
IF(NICK_ID IS NULL)
THEN
INSERT INTO _NICKS VALUES(ID, NAME) (NULL, 'NICK');
SELECT LAST_INSERT_ID() INTO 'NICK_ID';
END IF;

SELECT ID FROM _SERVERS WHERE SERVER = 'SERVER' INTO 'SERVER_ID';
IF('SERVER_ID' IS NULL)
THEN
INSERT INTO _SERVERS VALUES(ID, SERVER) (NULL, 'SERVER');
SELECT LAST_INSERT_ID() INTO 'SERVER_ID';
END IF;

SELECT ID FROM _NETS WHERE NET = 'NET' INTO 'NET_ID';
IF(@NET_ID IS NULL)
THEN
INSERT INTO _NETS VALUES(ID, NETS) (NULL, 'NET');
SELECT LAST_INSERT_ID() INTO 'NET_ID';
END IF;

INSERT INTO _CONTACTS VALUES(ID, NAME1_ID, NAME2_ID, NAME3_ID, NICK_ID,
SERVER_ID, NET_ID) (NULL, NAME1_ID, NAME2_ID, NAME3_ID, NICK_ID, SERVER_ID,
NET_ID);
--SET OUTPUT_PARAM = LAST_INSERT_ID();

END //
DELIMITER ;

[Soren Bro]

I've figured out the proper joins. For some reason the Stored Procedure
CALL complains about wrong number of arguments. I have it absurdly
normalized. The MESSAGES table will reference itself, Possibly with a
compostite PRIMARY KEY.. This will make making a tree view of discussions a
breeze. ODBC bulk row fetching will make enomously amounts of accounts
showable lightning fast in a Windows C++ Virtual CListCrtl. I know
because I've implemented this before. I don't care if you have a million
contacts and a billion messages .This will be fast nonetheless. And as I
said it will lend itself beautifully to CTreeView with discussion ID's,
keepin track of which message is in answer to what..

Now, I'm obviouslt in my right element coding GUIs. All I need is a robust
database with "simple" Stored Proedures underneath,.

Then we are running.

And since mysql is available on all platforms portability should ber a
breeze too. Give me a little chance to demonstrate this for you. I'm sure
you wont regret it. A program with data amounts this size should reallybe
using a (properly normalized) database....

Regards,

On Mon, Mar 18, 2019 at 9:01 PM Soren Bro sbrothy@users.sourceforge.net
wrote:

It may look like I'm doing nothing but believe me I'm in the fray - like my
ultimate idol Jean Parisot de Valette
https://en.wikipedia.org/wiki/Jean_Parisot_de_Valette, The Christian
Commander from The Siege of Malta in 1540. This guy slaughtered hordes of
oncoming enemies (they happened to be muslims, but that's ofcourse not
important, cough) with a two-handed sword I probably wouldn't be able to
lift, wearing full battle armor at the age of 70!!

I know you guys hate the underlying database idea, so I'm working both
ways. My SQL is a little rusty though. Give me a little time. A week or so
to blind you with science.... I'll get my science gun out.. (
http://amultiverse.com/tag/science-guns/)....

Sending and receving email should be fairly easy having the Eudora DLLs and
LIBs, so I´m investing a little time with the SQL way. And yes, I know you
hate me for it. On the other hand I work for free and there's no such thing
as a free lunch.... So what you see is what you get.

And to be brutally honest you haven´t seen much, Hmm....

This is a part of where I´m at with SQL, but it's a tiny part...Also, I'm
sure mysql is able to send emails. We just need to make it pretty. and THAT
at least I think I have shown I can do.

I'm further than this, but this was what was open in my textpad client...

Regards.

-- Start over.
DROP DATABASE HERMES;
CREATE DATABASE HERMES;
USE HERMES;

-- Create normalization and internal tables. If you find yourself forced to
maniplate one of these manually you're doing something wrong!
-- The '_' in front of names should be a giveaway. It basically means
"don't touch me". Use the proper Stored Procedures instead.
DROP TABLE _NAMES;
CREATE TABLE _NAMES (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, NAME
VARCHAR(50) NOT NULL UNIQUE);
DROP TABLE _NICKS;
CREATE TABLE _NICKS (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, NAME
VARCHAR(50) NOT NULL UNIQUE);
DROP TABLE _SERVERS;
CREATE TABLE _SERVERS (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, SERVER
VARCHAR(50) NOT NULL UNIQUE);
DROP TABLE _NETS;
CREATE TABLE _NETS (ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, NET
VARCHAR(50) NOT NULL UNIQUE);

-- Even this isn't supposed to be manipulated directly. There will be views
and, again, Stored Procedures for that.
DROP TABLE _CONTACTS;
CREATE TABLE _CONTACTS ( \ ID INT NOT NULL PRIMARY KEY, \ NAME1_ID INT,
FOREIGN KEY (NAME1_ID) REFERENCES _NAMES(ID), \ NAME2_ID INT, FOREIGN KEY
(NAME2_ID) REFERENCES _NAMES(ID), \ NAME3_ID INT, FOREIGN KEY (NAME3_ID)
REFERENCES _NAMES(ID), \ NICK_ID INT, FOREIGN KEY (NICK_ID) REFERENCES
_NICKS(ID), \ SERVER_ID INT, FOREIGN KEY (SERVER_ID) REFERENCES
_SERVERS(ID), \ NET_ID INT, FOREIGN KEY (NET_ID) REFERENCES _NETS(ID) \ );

DROP PROCEDURE AddContact;
DELIMITER //
CREATE PROCEDURE AddContact(IN EMAIL VARCHAR(50))
BEGIN
DECLARE WORK VARCHAR(50);
SELECT TRIM(EMAIL) INTO WORK;

SELECT WORK;
SELECT SUBSTRING_INDEX(WORK, '@', 1);
SELECT SUBSTRING_INDEX(WORK, '@', -1);
SELECT SUBSTRING_INDEX(WORK', '.', -1);

END //
DELIMITER ;

CALL AddContact(' sbrothy@gmail.com ');

DROP PROCEDURE AddContact;
DELIMITER //
CREATE PROCEDURE AddContact (IN EMAIL VARCHAR(50))
BEGIN
DECLARE WORK VARCHAR(50);

SELECT TRIM(EMAIL) INTO WORK;

SELECT WORK;

SELECT SUBSTRING_INDEX(WORK, '@', 1);
SELECT SUBSTRING_INDEX(WORK, '@', -1);
SELECT SUBSTRING_INDEX(WORK, '.', 1);
SELECT SUBSTRING_INDEX(WORK', '.', -1);

END
//
DELIMITER ;

CALL AddContact('sbrothy@gmail.com');

SELECT SUBSTRING_INDEX(TEMAIL, '@', 1) INTO NICK;
SELECT SUBSTRING_INDEX(TEMAIL, '@', -1) INTO WORK;
SELECT SUBSTRING_INDEX(WORK, '.', 1) INTO SERVER;
SELECT SUBSTRING_INDEX(WORK', '.', -1) INTO NET;

SELECT NICK;
SELECT WORK;
SELECT SERVER;
SELECT NET;

SELECT ID FROM _NICKS WHERE NICK = @NICK INTO @NICK_ID;
IF(@NICK_ID IS NULL)
THEN
INSERT INTO _NICKS VALUES(ID, NAME) (NULL, @NICK);
SELECT LAST_INSERT_ID() INTO @NICK_ID;
END IF;

SELECT ID FROM _SERVERS WHERE SERVER = @SERVER INTO @SERVER_ID;
IF(@SERVER_ID IS NULL)
THEN
INSERT INTO _SERVERS VALUES(ID, SERVER) (NULL, @SERVER);
SELECT LAST_INSERT_ID() INTO @SERVER_ID;
END IF;

SELECT ID FROM _NETS WHERE NET = @NET INTO @NET_ID;
IF(@NET_ID IS NULL)
THEN
INSERT INTO _NETS VALUES(ID, NETS) (NULL, @NET);
SELECT LAST_INSERT_ID() INTO @NET_ID;
END IF;

INSERT INTO _CONTACTS VALUES(ID, NAM1E_ID, NAME2_ID, NAME3_ID, NICK_ID,
SERVER_ID, NET_ID) (NULL, NULL, NULL, NULL, @NICK_ID, @SERVER_ID, @NET_ID);

CREATE TABLE _MESSAGES ( \ ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, \ RECEIVERS BLOB, \ BCCS BLOB, \ CCS BLOB \ );

---

DROP PROCEDURE AddContact;
DELIMITER //
CREATE PROCEDURE AddContact (IN EMAIL VARCHAR(50))
BEGIN
DECLARE 'WORK' VARCHAR(50);
DECLARE 'TEMAIL' VARCHAR(50);
DECLARE 'NICK' VARCHAR(50);
DECLARE 'NICK_ID' INT DEFAULT NULL;
DECLARE 'SERVER' VARCHAR(50);
DECLARE 'SERVER_ID' INT DEFAULT NULL;
DECLARE 'NET' VARCHAR(50);'
DECLARE 'NET_ID' INT DEFAULT NULL;'

DECLARE 'NAME1_ID' INT DEFAULT NULL;
DECLARE 'NAME2_ID' INT DEFAULT NULL;
DECLARE 'NAME3_ID' INT DEFAULT NULL;

SELECT TRIM('EMAIL') INTO 'TEMAIL';

SELECT 'TEMAIL';

SELECT SUBSTRING_INDEX('TEMAIL', '@', 1) INTO 'NICK';

SELECT 'NICK';

SELECT SUBSTRING_INDEX('TEMAIL', '@', -1) INTO 'WORK';

SELECT 'WORK';

SELECT SUBSTRING_INDEX('WORK', '.', 1) INTO 'SERVER';

'SELECT 'SERVER;

SELECT SUBSTRING_INDEX(@WORK', '.', -1) INTO NET;

SELECT NET;

SELECT ID FROM _NICKS WHERE NICK = 'NICK' INTO NICK_ID;
IF(NICK_ID IS NULL)
THEN
INSERT INTO _NICKS VALUES(ID, NAME) (NULL, 'NICK');
SELECT LAST_INSERT_ID() INTO 'NICK_ID';
END IF;

SELECT ID FROM _SERVERS WHERE SERVER = 'SERVER' INTO 'SERVER_ID';
IF('SERVER_ID' IS NULL)
THEN
INSERT INTO _SERVERS VALUES(ID, SERVER) (NULL, 'SERVER');
SELECT LAST_INSERT_ID() INTO 'SERVER_ID';
END IF;

SELECT ID FROM _NETS WHERE NET = 'NET' INTO 'NET_ID';
IF(@NET_ID IS NULL)
THEN
INSERT INTO _NETS VALUES(ID, NETS) (NULL, 'NET');
SELECT LAST_INSERT_ID() INTO 'NET_ID';
END IF;

INSERT INTO _CONTACTS VALUES(ID, NAME1_ID, NAME2_ID, NAME3_ID, NICK_ID,
SERVER_ID, NET_ID) (NULL, NAME1_ID, NAME2_ID, NAME3_ID, NICK_ID, SERVER_ID,
NET_ID);
--SET OUTPUT_PARAM = LAST_INSERT_ID();

END //
DELIMITER ;

---

Threading water.
https://sourceforge.net/p/hermesmail/discussion/general/thread/6f8867730c/?limit=25#b235

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hermesmail/discussion/general/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Ted Matavka]

On Wednesday, March 20, 2019 3:30:34 PM EDT, Soren Bro wrote:

Now, I'm obviouslt in my right element coding GUIs. All I need is a robust
database with "simple" Stored Proedures underneath,.

Then we are running.

And since mysql is available on all platforms portability should ber a
breeze too.

Give me a little chance to demonstrate this for you. I'm sure
you wont regret it. A program with data amounts this size should reallybe
using a (properly normalized) database....

Consider these past few weeks "a little chance to demonstrate this" for us.
Now, I've been battling some personal issues (nothing like conflict,
addiction, or legal trouble, just... the results of applying shear stress
to a rheopectic fluid), which has lengthened my timeline somewhat. Still,
tonight I should have the first two official HERMES software products all
done, wrapped up, and posted on the official HERMES Web page.

Anyway, that just about ties up, with a neat little bow, why I haven't been
putting much work into the management role. So tonight's also my first
night back in THAT saddle.

I have made my opposition to the database idea abundantly clear on multiple
occasions. I'll explain why in the next paragraph, for now, just recognise
that reasons exist. I've implied several times that I'd offer you an
equity deal once we're mature enough as a business (you take home X percent
of the profits, you risk X percent of the losses). I also see that you are
an adamant supporter of the database idea, and that you're willing to go
some length to produce it. Finally, I recognise that you are a grown man,
and that what you do on your own time should not concern us, so long as
you're not doing it "on the company dime", in American speak.

The reasons why I don't like the database idea are first, that Eudora
doesn't use any sort of RDBMS. Not SeQueL, not MS Access, nothing. Which
means that as soon as we introduce one, the old-time Eudora people will
bitch and whine. Now, I can put up with that, but only as regards contacts
management (names and addresses), not mailstore. Second, NO mail client
now existing (and I've checked) uses an RDBMS for mailstore. Some use one
for contacts. Some use the MS Contacts API instead. Some use their own
thing. If we retool HERMES Mail to use RDB's, we're putting significant
work in to achieve this reality, but we can't sell that feature. Come on,
do you see either one of us going into a place of business and saying, "use
HERMES for your eMail needs, our software uses a database", and this
changes the pointy-haired boss's mind? No! Will it change the dotty,
tweedy old professor's mind, come to that? Fuck no! Thunderbird,
specifically (the MARKET LEADER in FOSS email solutions) uses Unix
mailstore format, just like us. Only a slightly different dialect. Easy
to translate between the two.

Now, I can't see a relational database being a Bad Thing on principle, and
there may come a time or a place or a circumstance when it's a plus point.
So let's not throw out the database idea. And again, it's not my place to
govern what grown men do with their hands in private (otherwise I'd have
half the planet in prison for masturbating). So here's my compromise: do
your database eMail program. Try to maintain look and feature parity
between the two. If the choice ever comes between the flat-file eMailer
and the database eMailer, pick the one with the flat file. If both work
out, though... I'll gladly market both, and we both walk out of here with
twice the glory, twice the money. Did you not think I'd come up with a few
ideas to monetise this thing?

[Soren Bro]

I'll get back to you on this. Just got up.

/Søren

On Thu, Mar 28, 2019 at 7:49 AM Ted Matavka nmatavka@users.sourceforge.net
wrote:

On Wednesday, March 20, 2019 3:30:34 PM EDT, Soren Bro wrote:

Now, I'm obviouslt in my right element coding GUIs. All I need is a robust
database with "simple" Stored Proedures underneath,.

Then we are running.

And since mysql is available on all platforms portability should ber a
breeze too.

Give me a little chance to demonstrate this for you. I'm sure
you wont regret it. A program with data amounts this size should reallybe
using a (properly normalized) database....

Consider these past few weeks "a little chance to demonstrate this" for
us.
Now, I've been battling some personal issues (nothing like conflict,
addiction, or legal trouble, just... the results of applying shear stress
to a rheopectic fluid), which has lengthened my timeline somewhat. Still,
tonight I should have the first two official HERMES software products all
done, wrapped up, and posted on the official HERMES Web page.

Anyway, that just about ties up, with a neat little bow, why I haven't
been
putting much work into the management role. So tonight's also my first
night back in THAT saddle.

I have made my opposition to the database idea abundantly clear on
multiple
occasions. I'll explain why in the next paragraph, for now, just recognise
that reasons exist. I've implied several times that I'd offer you an
equity deal once we're mature enough as a business (you take home X
percent
of the profits, you risk X percent of the losses). I also see that you are
an adamant supporter of the database idea, and that you're willing to go
some length to produce it. Finally, I recognise that you are a grown man,
and that what you do on your own time should not concern us, so long as
you're not doing it "on the company dime", in American speak.

The reasons why I don't like the database idea are first, that Eudora
doesn't use any sort of RDBMS. Not SeQueL, not MS Access, nothing. Which
means that as soon as we introduce one, the old-time Eudora people will
bitch and whine. Now, I can put up with that, but only as regards contacts
management (names and addresses), not mailstore. Second, NO mail client
now existing (and I've checked) uses an RDBMS for mailstore. Some use one
for contacts. Some use the MS Contacts API instead. Some use their own
thing. If we retool HERMES Mail to use RDB's, we're putting significant
work in to achieve this reality, but we can't sell that feature. Come on,
do you see either one of us going into a place of business and saying,
"use
HERMES for your eMail needs, our software uses a database", and this
changes the pointy-haired boss's mind? No! Will it change the dotty,
tweedy old professor's mind, come to that? Fuck no! Thunderbird,
specifically (the MARKET LEADER in FOSS email solutions) uses Unix
mailstore format, just like us. Only a slightly different dialect. Easy
to translate between the two.

Now, I can't see a relational database being a Bad Thing on principle, and
there may come a time or a place or a circumstance when it's a plus point.
So let's not throw out the database idea. And again, it's not my place to
govern what grown men do with their hands in private (otherwise I'd have
half the planet in prison for masturbating). So here's my compromise: do
your database eMail program. Try to maintain look and feature parity
between the two. If the choice ever comes between the flat-file eMailer
and the database eMailer, pick the one with the flat file. If both work
out, though... I'll gladly market both, and we both walk out of here with
twice the glory, twice the money. Did you not think I'd come up with a few
ideas to monetise this thing?

---

Threading water.
https://sourceforge.net/p/hermesmail/discussion/general/thread/6f8867730c/?limit=25#b235/be71/984b

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/hermesmail/discussion/general/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/