Hello Marck, On Fri, 12 Jul 2002 11:17:56 +0100 GMT (12/07/02, 17:17 +0700 GMT), Marck D Pearlstone wrote:
TF>> ... I would think it is time for a seperate addressbook program TF>> into which email clients, PIMs, and other application can hook TF>> into... MDP> I don't get it. I am proposing a seperate program for address maintanance. MDP> Still the language problem persists. Here's why I prize the TB MDP> "address book" (let's call it the email address manager, because MDP> that's what it really is): MDP> Multiple email addresses per entry This would be in my proposed AB database. MDP> Group templates MDP> Individual templates per entry TB would still need a module that hooks into the database. Assuming that no other program might need the templates, these could be owned by TB and not the central AB database, if you so wish. That does not change the fact that the email address / name / phone number etc dsiplayed in the module of TB is really data read from the central database. MDP> Tight interaction between filters / groups / multiple addresses MDP> Integration with macros (%AB.....) No problem here. TB will need to read the central database anyway, so these functions will still be possible. MDP> Address auto-view giving a "video-mail" like capability when the MDP> photo facility is used. The photo could still be in the central database. MDP> *Every one* of these superb features would be compromised (interfered MDP> with) by the use of an external AB or PIM. No PIM would even *want* to MDP> hold the kind of information used to give this functionality. No, a PIM would not. A PIM would only read the info that it is interested in. But, if I update the email address or phone number from within the PIM or from within TB, the central database will be updated. I do not need to change from within the PIM, then from within TB, then from within .... MDP> I don't want addresses and phone numbers in TB. TB doesn't need to read them in. MDP> The TB email address manager ROCKS! Just stop calling it an Address MDP> Book and it suddenly looks *so* fit for purpose. I don't think my proposal includes cutting down on functionality. It is only that data that is probably used by multiple applications doesn't need to be stored by each application seperately. Duplication would thus be avoided, and so would synchronisation issues. For the user it would be transparent; he would even know whether the data comes from within TB or from a central database. MDP> Sure, all names in one place has merit on paper, but clear thought and MDP> analysis shows what a waste of space it would be to chuck all people MDP> data in one place. I think we would be avoiding duplication. A main point is synchronisation of databases which would not be necessary any more. MDP> I just haven't seen one that isn't full of holes and fuzzy MDP> thinking yet. That is another issue. You are probably right that what I suggest does not exist yet. A good email client didn't exist either before two novice programmers started writing TB... ;-) -- Cheers, Thomas. Moderator der deutschen The Bat! Beginner Liste. How can I miss you if you won't go away? Message reply created with The Bat! 1.61 under Chinese Windows 98 4.10 Build 2222 A using an AMD Athlon K7 1.2GHz, 128MB RAM ________________________________________________________ Current Ver: 1.60q FAQ : http://faq.thebat.dutaint.com Unsubscribe: mailto:[EMAIL PROTECTED] Archives : http://tbudl.thebat.dutaint.com Moderators : mailto:[EMAIL PROTECTED] TBTech List: mailto:[EMAIL PROTECTED] Bug Reports: https://www.ritlabs.com/bt/
