I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with corresponding
foreign keys and attributes like "Original Post" (Likely to be a thread
starter), "thread id" perhaps, ("Person/organisation" (binary pattern, so
contact can be both), "subject", "Addressees", (sender/recevier/cc/bcc,
BLOBS, linked lists or vectors), "contents" (BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents" (BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
Listen to me. There will not be any RDBMSes or any other formats included
in HERMES v. 8. Full stop. I have taken one quasi-unplugged day and this
is what I come back to?!
The mail format of Eudora is the same as for BSD UNIX mail. We will
continue using that format. If we include an RDBMS format in HERMES mail
9, that'll be great, but only at the user's choice, and not before HERMES 8
is released! Understood? This will impact negatively on release time, and
I WILL NOT HAVE INVESTORS BREATHING DOWN MY NECK. Not our collective
necks. MY neck.
Heh, I've written myself into a beautiful cul-de-sac here.... I'm gonna
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
Listen to me. There will not be any RDBMSes or any other formats included
in HERMES v. 8. Full stop. I have taken one quasi-unplugged day and this
is what I come back to?!
The mail format of Eudora is the same as for BSD UNIX mail. We will
continue using that format. If we include an RDBMS format in HERMES mail
9, that'll be great, but only at the user's choice, and not before HERMES 8
is released! Understood? This will impact negatively on release time, and
I WILL NOT HAVE INVESTORS BREATHING DOWN MY NECK. Not our collective
necks. MY neck.
On Sat, 9 Feb 2019 at 07:08, Soren Bro sbrothy@users.sourceforge.net
wrote:
Heh, I've written myself into a beautiful cul-de-sac here.... I'm gonna
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
The mail format of Eudora is the same as for BSD UNIX mail. We will
continue using that format. If we include an RDBMS format in HERMES mail
9, that'll be great, but only at the user's choice, and not before HERMES 8
is released! Understood? This will impact negatively on release time, and
I WILL NOT HAVE INVESTORS BREATHING DOWN MY NECK. Not our collective
necks. MY neck.
On Sat, 9 Feb 2019 at 07:08, Soren Bro sbrothy@users.sourceforge.net
wrote:
Heh, I've written myself into a beautiful cul-de-sac here.... I'm gonna
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
at, but only at the user's choice, and not before HERMES 8
is released! Understood? This will impact negatively on release time, and
I WILL NOT HAVE INVESTORS BREATHING DOWN MY NECK. Not our collective
necks. MY neck.
On Sat, 9 Feb 2019 at 07:08, Soren Bro sbrothy@users.sourceforge.net
wrote:
Heh, I've written myself into a beautiful cul-de-sac here.... I'm gonna
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
On Sat, 9 Feb 2019 at 07:08, Soren Bro sbrothy@users.sourceforge.net
wrote:
Heh, I've written myself into a beautiful cul-de-sac here.... I'm gonna
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with
corresponding foreign keys and attributes like "Original Post" (Likely to
be a thread starter), "thread id" perhaps, ("Person/organisation" (binary
pattern, so contact can be both), "subject", "Addressees",
(sender/recevier/cc/bcc, BLOBS, linked lists or vectors), "contents"
(BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
------------------------------
Soren...what you're talking about here is way above my pay grade.
I have aproxx 100 mailboxes and 4gb worth of data. That's nothing compared to what others have. Eudora has no other way of organizing mail other than by mailbox and subfolders of that mailbox...that I'm aware of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hadn't really fathomed the numbers involved in your email activity. How
Eudora keeps track of these data amounts without a proper RDBMS beneath it
,is beyond me. It must be a mess.
So just a hypothtical experiment:
Someone (Walt?) mentioned several thousand "mailboxes" (contacts? internal
/ external?) and millions of messages.
If anything Eudora should really be a thin client on top of a database
system with the simple ability to send and receive mails. For a real
power-user maybe even an Oracle TOAD style program would be enough with a
proper command of SQL. Stored Procedures could be utilised. A vitual
CListCtrl with mass fetching of records on top of that.
Now, I can imagine tables like "MESSAGES" and "CONTACTS" with corresponding
foreign keys and attributes like "Original Post" (Likely to be a thread
starter), "thread id" perhaps, ("Person/organisation" (binary pattern, so
contact can be both), "subject", "Addressees", (sender/recevier/cc/bcc,
BLOBS, linked lists or vectors), "contents" (BLOB?)
Normalization would move names to separate tables (lots of people called
"Jensen", Nielsen" and "Rasmussen" just in this small country (Denmark).
(Northumbria University has this new database system called Raquel. Maybe
manpower can be negotiated with them if we use that.)
I may have talked about this before. Anyway. Just putting it out there,
while I try to get a simple button to work....
Regards,
Søren
Heh, I've written myself into a beautiful cul-de-sac here.... I'm gonna
think about this a bit.... Try again to put the code up too...
Regards,
Søren
On Sat, Feb 9, 2019 at 11:38 AM sbrothy@gmail.com wrote:
Listen to me. There will not be any RDBMSes or any other formats included
in HERMES v. 8. Full stop. I have taken one quasi-unplugged day and this
is what I come back to?!
The mail format of Eudora is the same as for BSD UNIX mail. We will
continue using that format. If we include an RDBMS format in HERMES mail
9, that'll be great, but only at the user's choice, and not before HERMES 8
is released! Understood? This will impact negatively on release time, and
I WILL NOT HAVE INVESTORS BREATHING DOWN MY NECK. Not our collective
necks. MY neck.
On Sat, 9 Feb 2019 at 07:08, Soren Bro sbrothy@users.sourceforge.net
wrote:
--
----- BEGIN TECO SIGNATURE BLOCK -----
32UD44UE97UR99UM101UA104UT106UO107UG110UL111UY114UP115UH116UI117UC$
QA:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QE:^UQ$QO:^UU$QC:^UU$QH:^UU$QI:^UU$QD:^UU$QM:^UI$QY:^UI$QD:^UI$
QT:^UI$QR:^UI$QR:^UB$QL:^UB$QY:^UB$QI:^UB$QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
----- END TECO SIGNATURE BLOCK -----
(Don't forget: ^ in TECO means just that, and $ means press the Esc key!)
Agreed. Separate text mailboxes are much easier to sync than whopping
single file datavases.
Cheers,
Rob
On Mon, 11 Feb 2019 at 23:37, Ted Matavka nmatavka@users.sourceforge.net
wrote:
to?!
at, but only at the user's choice, and not before HERMES 8
DOWN MY NECK. Not our collective
autiful cul-de-sac here.... I'm gonna
l.com wrote:
s beyond me. It must be a mess.
ions of messages.
user maybe even an Oracle TOAD style program would be enough with a
records on top of that.
a thread starter), "thread id" perhaps, ("Person/organisation" (binary
lists or vectors), "contents"
l country (Denmark).
lked about this before. Anyway. Just putting it out there,
users? Data amounts? Client Looks?
sit
:^US$QP:^US$QD:^US$QI:^US$QA:^US$QM:^UQ$QG:^UQ$QA:^UQ$QP:^UQ$
QT:^UB$GI-5CGUGS-5CGB10CGQ0JT$$
Robert Czernkowski, PhD, BCom(Hons), FCPA
Soren...what you're talking about here is way above my pay grade.
I have aproxx 100 mailboxes and 4gb worth of data. That's nothing compared to what others have. Eudora has no other way of organizing mail other than by mailbox and subfolders of that mailbox...that I'm aware of.