From: Simon T. <tur...@nt...> - 2002-09-15 14:49:40
|
Is there a development plan/roadmap anywhere. I'm trying to get my head around where Squirrelmail is going so I can work out where I can be of assistance. Cheers, Simon |
From: Marc G. K. <ma...@it...> - 2002-09-15 17:24:05
|
> Is there a development plan/roadmap anywhere. I'm trying to get my head > around where Squirrelmail is going so I can work out where I can be of > assistance. > > Cheers, > Simon > Good question Simon. If have certain ideas about directions but i don't know how the rest thinks about it. A discussion about SM directions and roadmap/plans is very welcome I think. The ideas I have and parts of them are already discussed with Paul Joseph Thompson are as follows (maybe the used terms differs from the terms Paul used): 1) Developing a MessageService base class with only message related functions. 2) Developing backend classes for the message base class. Explanation how I see 1 and 2: The base contains all the nescecarry functions needed by the different SM parts. The functions are like: GetMessage, FlagMessage, CopyMessage, Get MailboxList, CreateMailbox, GetMessages (mailbox_display at this moment) etc etc. The functions look like this: function GetMessage($mailbox, $id) { return $backend->GetMessage($mailbox,$id); } Nothing more, except that we have to define exactly in what form we expect the result. The backend modules can be anything, imap, php-imap, maildir etc etc. By initiating the baseclass we also create the backend class. What backend we create depends on config settings. If the backend is imap we also can do something with the capabilities return of imap to identify what sort of imap-server we are dealing with. The imap backend is a imap base class which is 100% RFC2060 compattible and extended classes for the different imapserver implementations where the overrided functions from the imap-base class are located. (in case the specific imap-server needs special treatment) An advantage of extended backend classes is lesser overhead. We don't have to deal anymore with the different imap-implementations in one function. No if imapserver = A then do this elseif imapserver=B then do that .... anymore. After we finished that (or before) we should create functions which are responsable for composing a message. Those functions should also handle replying to html mail, composing html mail etc etc. 3) Redesign the addresbook to a vCard interface. 4) Making SM modulair to support extra additions to SM (sort of groupware sollution) 5) Redesign the preference system in such way that administraters can decide what options are available to users and what are the default options. Maybe we also should consider usergroup support so we can have different options for different groups. 6) Implement Smarty-templates In the meantime we can re-evaluate the SM-code at this moment and recode the bad parts in SM. If we move certain pieces of SM-code to backend classes or whatever we can use it. I also want a technical discussion about the best way to implement dynamic backends. I have my ideas but I bet there are more developers with good ideas so we can choose the best sollution. Keep in mind that it isn't easy to decide what's best. Keep also in mind that performance related discussions should be relevant. I'm aware of slower behaviour of classes but more important is what are the bottlenecks. I think the bottleneck is the imap-communication and the not smart programmed routines (there are lots of them in SM for example mailbox-list). We realy should find out what performance related issues are relevant and which aren't. Arguments like A = slow and B isn't I don't want to see. Explain why A is slow and proof it is relevant. (this is my personal opinion, you can fight me on that) Simple example of a routine what is used everywhere in SM and what can be much quicker is the following: for ($i=0; $i<count($array);$i++) { etc. if you want performance then you should this: for ($i=0, $cnt=count($array);$i<$cnt,$i++) { etc. same counts for if A elseif B elseif C => should be switch case A case B case C. What I mean is that by smarter programming we can achieve very simple much more performance. I think it's very important that the SM-admins give feedback on this so we can finally make a roadmap/plan. The last half year there was communication between the sm-developers but I never saw a roadmap or whatever discussed on the devel-list (maybe I didn't look good). I think the time is right now! Let's start this thread and make it bigger then the flamewar thread :-) Regards, Marc Groot Koerkamp > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > http://squirrelmail.org/cvs > |
From: Simon T. <tur...@nt...> - 2002-09-15 18:40:38
|
I agree pretty much with all you've said. The problem is that the individual developers' ideas as to where Squirrelmail should be going really needs to be distilled into some kind of concrete roadmap, preferably with milestone goals. Once the goals are established then design can begin on particular subsystems like the mail delivery backends. I mentioned earlier that I'd quite like to see a design document/specification for a 'mail service abstraction layer' or in other words, a base class for each of the sending and receiving aspects of mail delivery. To this end we should define a set of core functions for the delivery/sender classes the implementation of which is a minimum requirement for a working Squirrelmail send/receive module. So, what about it? Simon |
From: Erin S. <si...@ha...> - 2002-09-16 00:04:28
|
So, now that the dev list is again talking about dev, I have a few things: ONE - The DEV CVS data_dir fix: Has ANYONE tried the fix to conf.pl I posted yet? I mean, having the dev CVS broken with people unable to log in seemed pretty serious, but I haven't heard anything about anyone testing my fix. YEESH. I would like a LITTLE feedback before I go putting it in CVS (since people are all bent about CVS right now anyway) so PLEASE PLEASE TEST IT! Send a note to me if you need the tarball again (not that it's big, just that Idon't want to post it AGAIN). :-P TWO - Zookeeper: I think Paul should also clarify what effort will go towards getting things ready for ZooKeeper, and what intermediate steps should be made in the SquirrelMail development stream to keep it evolving. Paul and I have talked about what he sees coming, and I think it's up to him to get all his thoughts in a format we can work with. THREE - The new Addressbook: I've been working (with Paul's blessing) on the beginnings of a design for the new Addressbook that will conform to the ZooKeeper model. To be honest, having a vCard interface was not on my list as a core part of the new Addressbook.. It should certainly support and interact with vCards, but I don't see that being a core requirement - should be an add-on module, in my opinion. I do have the following items as a poll for your feedback (I'll get the design together and will post it - hopefully in CVS within whatever area Paul has decided is appropriate so that everyone can hack it to bits): 1. I think we want (at the LEAST): Support for individual addresses - adding from email to/from/cc fields - using nicknames Support for address groups - basically nickname for multiple people Standard address book features - search/sort/list - autocomplete in To/CC/BCC fields? - add/remove - import/export 2. Address information: Currently thinking of three levels of contact info Basic - Full Name, Nickname, email Business - Basic + Business-type telephone/address information Family - Basic + Family-oriented information (addr + anniversary/birthday) There are two ways to use these levels, either as attributes of the entire address book (what kind of site is it) OR as an attribute of the address itself (since we only need the basic elements to address mail, having a blob containing the rest of the information would hardly hurt.. something to chew on in any case). 3. Address books - only one? I think we need support for multiple address books. At LEAST, we have the personal address books. I think we should offer (within the Zookeeper structure) support for group address books (common for groups of users - a global address book would be a special case where the group of users happens to include everybody). There will have to be some determination for how you decide who can or can't edit addresses in group address books, but I think that's a long way off yet. SO, I'd like some opinions. Common elements that every address book entry should have? Do you think having different levels is stupid? If there were personal and group address books, should the listings be intermingled or separate? Some of that is sort of low-level, especially for this early in the design, but I wanted to throw it in there just to see what you guys thought. The address book and the Calendar are the two things I think need the most work, so I volunteered to get the Address Book re-written. Let me know what you think. And darnit! Try out that data_dir fix! Erin (sizzle) -- 'Waste of a good apple.' ~Samwise Gamgee ICQ: 38670353 |
From: Alvaro Munoz-A. Mtnz. <alv...@ay...> - 2002-09-16 02:30:59
|
At the moment only comments to number 3, below Erin Schnabel wrote: > THREE - The new Addressbook: > I've been working (with Paul's blessing) on the beginnings of a design > for the new Addressbook that will conform to the ZooKeeper model. To > be honest, having a vCard interface was not on my list as a core part > of the new Addressbook.. It should certainly support and interact with > vCards, but I don't see that being a core requirement - should be an > add-on module, in my opinion. > I do have the following items as a poll for your feedback (I'll get > the design together and will post it - hopefully in CVS within > whatever area Paul has decided is appropriate so that everyone can > hack it to bits): > > 1. I think we want (at the LEAST): > Support for individual addresses > - adding from email to/from/cc fields > - using nicknames > Support for address groups > - basically nickname for multiple people > Standard address book features > - search/sort/list > - autocomplete in To/CC/BCC fields? > - add/remove > - import/export > Everything here looks great, I find autocomplete quite useful I use it all the time instead of looking up and opening a record. > 2. Address information: > Currently thinking of three levels of contact info > Basic - Full Name, Nickname, email > Business - Basic + > Business-type telephone/address information > Family - Basic + > Family-oriented information (addr + anniversary/birthday) Dates on the info, hmm that leads us to calendar.... For the rest seems ok > There are two ways to use these levels, either > as attributes of the entire address book (what kind of site is it) > OR as an attribute of the address itself (since we only need > the basic elements to address mail, having a blob containing > the rest of the information would hardly hurt.. something to chew > on in any case). > > 3. Address books - only one? > I think we need support for multiple address books. > At LEAST, we have the personal address books. > I think we should offer (within the Zookeeper structure) > support for group address books (common for groups > of users - a global address book would be a special case > where the group of users happens to include everybody). > There will have to be some determination for how you > decide who can or can't edit addresses in group address > books, but I think that's a long way off yet. > Well, usually there is support for multiple address books (for personal use and to share), althought for a first thing a personal address book is ok, lots of people ask sometime if they can share an address book so everybody can lookup one and a webmail is the place where ppl like that :-P > SO, I'd like some opinions. > Common elements that every address book entry should have? Do you think > having different levels is stupid? If there were personal and group > address books, should the listings be intermingled or separate? > > Some of that is sort of low-level, especially for this early in the > design, but I wanted to throw it in there just to see what you guys > thought. The address book and the Calendar are the two things I think need > the most work, so I volunteered to get the Address Book re-written. > hmm anyway a convination of a bug and a wiki entry to talk about this kind of things is better than using the list, imho is a bit cumbersome to follow up the mails. > Let me know what you think. > And darnit! Try out that data_dir fix! > > Erin > (sizzle) > > -- > 'Waste of a good apple.' ~Samwise Gamgee > ICQ: 38670353 > Alvaro |
From: WJCarpenter <bil...@ca...> - 2002-09-16 17:06:02
|
> THREE - The new Addressbook: Individual address book entries should have at least one datestamp automatically applied: date last modified. Even better, two date stamps: date last modified and date created. Even if the address book core software doesn't do anything with those datestamps (though I imagine displaying them wouldn't be too much trouble), having them empowers potential "maintenance" plug-ins. |
From: Paul J. T. <cap...@sq...> - 2002-09-16 22:42:08
|
A new job for Erin: Please do your best to summarize these comments, input, etc, somewhere in the wiki. I will leave the place to you, just put it somewhere that makes sense. Put it in some kind of "planning" or development corner, or whatnot. I don't want us to move ALL of the discussion off the list and onto the wiki, just the "record". The list is a much more high traffic media for planning. As for my comments... We DON'T want to base the addressbook explicitly on vCard. Rather, vCard would be an export format or whatnot, not the core. One more assignment for WHOEVER wants to take it: I would appreciate VERY HIGHLY if someone would take the time to research a handful of the most common addressbook specs and present some sort of a report to the development team. This will help us decide what we want to include. First, I would like to ask people for a list of what they think are the most logical candidates for consideration on this list. Here is a starting suggestion list. Please reply-to-list and add to it: 1. vCard 2. Outlook (sorry, but it is a standard of sorts) 3. Lotus Notes (Notes users out there?) 4. Evolution I am SURE there are at least 3 or 4 or more other IMPORTANT (or not so important) things to include for consideration/comparison. Second, take that list and make a chart. Along the top, list the different example specs. And along the left, list fields present in any of the address book specs. Then, in the center of the chart, put an X or lack of X that tells us which fields are present. Maybe throw a column up there that counts the total addressbook count or percentage for each field. Something like this: | A | B | C | D | E | F | G ------------+---+---+---+---+---+---+--- First Name | X | X | X | X | | X | Last Name | X | X | X | X | X | X | Email Addr | X | X | X | X | X | X | X Home Phone | | X | X | | | X | Birthday | | X | | | | X | etc, etc | | | X | | | | X Legend: A = vCard B = Microsoft Outlook C = Lotus Notes D = Evolution E = Other Address Book Format 1 F = Other Address Book Format 2 G = Other Address Book Format 3 Of course, we could add as many fields and addressbooks to this as we want. One request - let's NOT try to do this in ASCII on the mailing list. That just sounds too disturbing. I will leave the format (just make it pretty and easy to comprehend!) to whoever volunteers. This is a GREAT job for one of you folks who have volunteered to help and I told you to check out things on the development list. Paul >> THREE - The new Addressbook: > > Individual address book entries should have at least one datestamp > automatically applied: date last modified. Even better, two date > stamps: date last modified and date created. > > Even if the address book core software doesn't do anything with > those datestamps (though I imagine displaying them wouldn't be too > much trouble), having them empowers potential "maintenance" plug-ins. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > http://squirrelmail.org/cvs > -- Paul Joseph Thompson cap...@sq... AIM/Yahoo/MSN IM: Captain Bunzo ICQ Number: 38801719 |
From: Simon T. <tur...@nt...> - 2002-09-17 06:46:37
|
> We DON'T want to base the addressbook explicitly on vCard. Rather, > vCard would be an export format or whatnot, not the core. > > One more assignment for WHOEVER wants to take it: I would appreciate > VERY HIGHLY if someone would take the time to research a handful of > the most common addressbook specs and present some sort of a report to > the development team. This will help us decide what we want to > include. Right, I'll take this on then. > First, I would like to ask people for a list of what they think are > the most logical candidates for consideration on this list. Here is a > starting suggestion list. Please reply-to-list and add to it: > > 1. vCard > 2. Outlook (sorry, but it is a standard of sorts) > 3. Lotus Notes (Notes users out there?) > 4. Evolution Good idea. If people could CC me explicitly too then that would be handy. Simon |
From: Marc G. K. <ma...@it...> - 2002-09-18 21:12:08
|
Erin Schnabel zei: <snip> > THREE - The new Addressbook: > I've been working (with Paul's blessing) on the beginnings of a design > for the new Addressbook that will conform to the ZooKeeper model. To > be honest, having a vCard interface was not on my list as a core part > of the new Addressbook.. It should certainly support and interact with > vCards, but I don't see that being a core requirement - should be an > add-on module, in my opinion. > I do have the following items as a poll for your feedback (I'll get > the design together and will post it - hopefully in CVS within > whatever area Paul has decided is appropriate so that everyone can > hack it to bits): > > 1. I think we want (at the LEAST): > Support for individual addresses > - adding from email to/from/cc fields > - using nicknames > Support for address groups > - basically nickname for multiple people > Standard address book features > - search/sort/list > - autocomplete in To/CC/BCC fields? > - add/remove > - import/export > > 2. Address information: > Currently thinking of three levels of contact info > Basic - Full Name, Nickname, email > Business - Basic + > Business-type telephone/address information > Family - Basic + > Family-oriented information (addr + anniversary/birthday) > There are two ways to use these levels, either > as attributes of the entire address book (what kind of site is it) > OR as an attribute of the address itself (since we only need > the basic elements to address mail, having a blob containing > the rest of the information would hardly hurt.. something to chew > on in any case). > Missed the blob the first time when I read this message. Sorry Erin for bothering you on ICQ with thoughts you already had yourself :-) Yes that's a very good idea. I think the sollution is implementation 1 with the basic fields we want to search on, show quick etc etc and store the rest in a blob as vCard (or some other format what's compattible with vCard). The link the a vCard whitepaper is : http://www.imc.org/pdi/vcardwhite.html That way we are very dynamic in our addresbookimplementations and don't have to worry about difficult db structures. About addressgroups: (from http://www.imc.org/pdi/vcard-21.rtf) a) vCard Grouping The vCard data stream can consist of multiple vCard objects. The vCard data stream can, sequentially, contain one or more vCard objects., In addition, the vCard data stream can contain a property whose value is a nested vCard. In both of these cases, each vCard object will be delimited by the vCard Delimiters. The vCard Reader conforming to this specification must be able to parse and process any of these combinations of vCard Groupings. The support for vCard Grouping is optional for a vCard Writer conforming to this specification. If we add an extra field group (boolean) to the database then we can store nested groups in the blob field. That means it is also possible to have groups with groups in it :-) and we still don't need a complicated db. Maybe an even better sollution is : db table: fields: id, displayable columns(serialized array), group (boolean), vCard (blob) That way we can choose what fields we want to be directly viewable. If we want for instance show the work related phonenumbers of a contactperson we simply add that field to the displayable columns. Minor detail is that we have to walk through the whole addresbook and parse every vCard to adapt the field displayable columns for every entry. So far my thoughts, let me hear what you think about it. Marc Groot Koerkamp. > > > Erin > (sizzle) > > -- > 'Waste of a good apple.' ~Samwise Gamgee > ICQ: 38670353 > |
From: Erin S. <si...@ha...> - 2002-09-19 14:04:09
|
Marc Groot Koerkamp said: > Missed the blob the first time when I read this message. Sorry Erin for > bothering you on ICQ with thoughts you already had yourself :-) > > Yes that's a very good idea. > > I think the sollution is implementation 1 with the basic fields we want > to search on, show quick etc etc and store the rest in a blob as vCard > (or some other format what's compattible with vCard). > > The link the a vCard whitepaper is : > http://www.imc.org/pdi/vcardwhite.html > > That way we are very dynamic in our addresbookimplementations and don't > have to worry about difficult db structures. > > About addressgroups: (from http://www.imc.org/pdi/vcard-21.rtf) > > a) vCard Grouping > The vCard data stream can consist of multiple vCard objects. The vCard > data stream can, sequentially, contain one or more vCard objects., In > addition, the vCard data stream can contain a property whose value is a > nested vCard. In both of these cases, each vCard object will be > delimited by the vCard Delimiters. The vCard Reader conforming to this > specification must be able to parse and process any of these > combinations of vCard Groupings. The support for vCard Grouping is > optional for a vCard Writer conforming to this specification. > > If we add an extra field group (boolean) to the database then we can > store nested groups in the blob field. > > That means it is also possible to have groups with groups in it :-) and > we still don't need a complicated db. > > Maybe an even better sollution is : > db table: > fields: id, displayable columns(serialized array), group (boolean), > vCard (blob) That way we can choose what fields we want to be directly > viewable. If we want for instance show the work related phonenumbers of > a contactperson we simply add that field to the displayable columns. > Minor detail is that we have to walk through the whole addresbook and > parse every vCard to adapt the field displayable columns for every > entry. > > So far my thoughts, let me hear what you think about it. > > Marc Groot Koerkamp. > AH!!! That is much better, Marc, Thanks! I know I'm an arm twister, but I figure others will have comments as well ;). So, maybe I will now try to explain the reasons I have for not making vCard "core" - though I think, with the resultant structure, you'll understand that it doesn't matter if it isn't core - it can still function that way! First: I don't assume that everyone will be running with a database. That would be the most effecient way, and I would certainly recommend it should we get to the shared addressbook situation, but it shouldn't be required. So, vCard, which seems like it might carry some structure overhead that would be useful in DB queries, would, I think be painful in the flat file case. Second: If we start with Paul's structure example: > > NEW SERVICES STRUCTURE: > + Configuration > * Contacts > + Contacts Export > + Contacts Storage > * Message > + Message Source > + Message Delivery > + Logging > + Authentication > + Calender I would change it to: + Configuration * Contacts + Contacts Import/Export - Uses a format - Uses a Persistor + Contact List - Typical add/remove etc. here - Uses a format - Uses a persistor + Contact Format - vCard - super-stripped-down-basic - SM unique format (per Simon's research) - possibly custom by site maintainer * Message + Message Source + Message Delivery + Logging + Authentication + Calender * Persistence (Storage, whatever) + FlatFile + MySQL + PostGRE + .... Something like that.. So what I was trying to get across Marc, is that not having vCard inherently designed in as the format of choice won't matter. You set your config up the right way, and your entire system will behave that way, See? But that way, for simpler, stripped down configs, we can keep to simpler formats. I'll take a look at the links you posted - maybe vCard will turn out to be the way to go in all cases, who knows. I am just reluctant to assume we're backending to a DB, because we may not be. And Paul - NO, I reread what you wrote, and I see it: > The Contacts service category would have the Person, Group, > etc, etc classes in it that formed the guts of Contacts > management. Then, Contacts Storage would (obviously) be a > service to frontend databases, ldap, or whatever. > And Contacts Export would provide different export > formats for a contact - vCard, etc. So yes, the Contacts Service Category WOULD have those classes that provide the "core" behavior for the Address book. Yeah. I like it. I'll let it ferment a little longer - and try to get this all together and pretty-like this weekend. OK. More comments. Keep 'em coming. and Paul, ICQ me when you get a chance, please? =) Erin (sizzle) -- 'Waste of a good apple.' ~Samwise Gamgee ICQ: 38670353 |
From: Marc G. K. <ma...@it...> - 2002-09-19 15:02:07
|
Erin Schnabel zei: > Marc Groot Koerkamp said: >> Missed the blob the first time when I read this message. Sorry Erin for >> bothering you on ICQ with thoughts you already had yourself :-) >> >> Yes that's a very good idea. >> >> I think the sollution is implementation 1 with the basic fields we want >> to search on, show quick etc etc and store the rest in a blob as vCard >> (or some other format what's compattible with vCard). >> >> The link the a vCard whitepaper is : >> http://www.imc.org/pdi/vcardwhite.html >> >> That way we are very dynamic in our addresbookimplementations and don't >> have to worry about difficult db structures. >> >> About addressgroups: (from http://www.imc.org/pdi/vcard-21.rtf) >> >> a) vCard Grouping >> The vCard data stream can consist of multiple vCard objects. The vCard >> data stream can, sequentially, contain one or more vCard objects., In >> addition, the vCard data stream can contain a property whose value is a >> nested vCard. In both of these cases, each vCard object will be >> delimited by the vCard Delimiters. The vCard Reader conforming to this >> specification must be able to parse and process any of these >> combinations of vCard Groupings. The support for vCard Grouping is >> optional for a vCard Writer conforming to this specification. >> >> If we add an extra field group (boolean) to the database then we can >> store nested groups in the blob field. >> >> That means it is also possible to have groups with groups in it :-) and >> we still don't need a complicated db. >> >> Maybe an even better sollution is : >> db table: >> fields: id, displayable columns(serialized array), group (boolean), >> vCard (blob) That way we can choose what fields we want to be directly >> viewable. If we want for instance show the work related phonenumbers of >> a contactperson we simply add that field to the displayable columns. >> Minor detail is that we have to walk through the whole addresbook and >> parse every vCard to adapt the field displayable columns for every >> entry. >> >> So far my thoughts, let me hear what you think about it. >> >> Marc Groot Koerkamp. >> > > AH!!! That is much better, Marc, Thanks! > > I know I'm an arm twister, but I figure others will have comments as well ;). > > So, maybe I will now try to explain the reasons I have for not making > vCard "core" - though I think, with the resultant structure, you'll > understand that it doesn't matter if it isn't core - it can still function > that way! Yes I do understand :-). But to make such structure you need to know exactly what is possible with vCard and what's not otherwise you never know if it can function exact the same way. I self defined structure which is compattible is probably better because you can remove some overhead. The blob objects gets smaller that way. > > First: > I don't assume that everyone will be running with a database. That would > be the most effecient way, and I would certainly recommend it should we > get to the shared addressbook situation, but it shouldn't be required. So, > vCard, which seems like it might carry some structure overhead that would > be useful in DB queries, would, I think be painful in the flat file > case. Sorry I was talking about databases but I think in databases and I know it should also be storable in flatfiles. serialize the database record is the key to flatfiles. Because we are limited in the implementation (flatfiles should work) we don't want an relational database. About structure overhead of vCards, there is no structure overhead :-) When I was talking about vCards containing vCards (groups) the structure is in the vCard itselfs and stored in the db blob (it's more easy to talk db). What you will see in the contactlist is the description of the vCard (the one which encapsolates the other vCards) and that it is a group because the groupbit is set. You don't need to know what persons are included in the vCard blob. if you open it then the vCard is parsed and you can see the group members. Sure the addresbook implementation should offer you the possibility to extract the included vCards and store it as a complete new contact. (or extract an included group) > > Second: > If we start with Paul's structure example: >> >> NEW SERVICES STRUCTURE: >> + Configuration >> * Contacts >> + Contacts Export >> + Contacts Storage >> * Message >> + Message Source >> + Message Delivery >> + Logging >> + Authentication >> + Calender > > I would change it to: > + Configuration > * Contacts > + Contacts Import/Export > - Uses a format > - Uses a Persistor > + Contact List > - Typical add/remove etc. here > - Uses a format > - Uses a persistor > + Contact Format > - vCard > - super-stripped-down-basic > - SM unique format (per Simon's research) > - possibly custom by site maintainer > * Message > + Message Source > + Message Delivery > + Logging > + Authentication > + Calender > * Persistence (Storage, whatever) > + FlatFile > + MySQL > + PostGRE > + .... > > Something like that.. So what I was trying to get across Marc, is that not > having vCard inherently designed in as the format of choice won't matter. > You set your config up the right way, and your entire system will behave > that way, See? But that way, for simpler, stripped down configs, we can > keep to simpler formats. I'll take a look at the links you posted - maybe > vCard will turn out to be the way to go in all cases, who knows. I am just > reluctant to assume we're backending to a DB, because we may not be. Only the frontend is responsable for the offered possibilities. If you want a simple frontend that's okay but the backend should support also complicated frontends (many fields like work / family etc etc). I do not exactly understand what you mean with simpler stripped down configs. If you mean a non relational db then it's OK because i didn't have one in mind. For the rest I think that everyone should read the related vCard documents (http://www.imc.org) and see what is possible with addresbooks. If we want to interchange information with other apps or pda's then it's a must to have vCard knowledge. If you're done with that you can start on the vCalendar documentation which is much more complicated :-) Regards, Marc Groot Koerkamp. |
From: Paul J. T. <cap...@sq...> - 2002-09-19 17:20:24
|
> First: > I don't assume that everyone will be running with a database. > That would be the most effecient way, and I would certainly > recommend it should we get to the shared addressbook situation, > but it shouldn't be required. So, vCard, which seems like it > might carry some structure overhead that would be useful in DB > queries, would, I think be painful in the flat file case. Right-o. > Second: > If we start with Paul's structure example: >> >> NEW SERVICES STRUCTURE: >> + Configuration >> * Contacts >> + Contacts Export >> + Contacts Storage >> * Message >> + Message Source >> + Message Delivery >> + Logging >> + Authentication >> + Calender > > I would change it to: > + Configuration > * Contacts > + Contacts Import/Export > - Uses a format > - Uses a Persistor > + Contact List > - Typical add/remove etc. here > - Uses a format > - Uses a persistor > + Contact Format > - vCard > - super-stripped-down-basic > - SM unique format (per Simon's research) > - possibly custom by site maintainer > * Message > + Message Source > + Message Delivery > + Logging > + Authentication > + Calender > * Persistence (Storage, whatever) > + FlatFile > + MySQL > + PostGRE > + .... Hmmnn. A lot to think about, I think. A couple comments. FIRST, just to make sure we are all on the same page here, the research Simon is doing will likely produce the list of fields that we decide to store in the Contact List itself, so really has more to do with the "Contacts List" service. In fact, now that I think about it, "SM unique format" really doesn't belong, unless we code something up to be a way to export/import the addressbook ourselves. Probably a bad idea, though, as we would be much better off finding some sort of standard out there. SECOND, I am a little - no a LOT - nervous about the persistor idea. On one hand, it is a GREAT idea with SO FREAKING MUCH potential that I don't know what to say. HOWEVER. By the basic ways that storage works, it makes me really nervous. When we store the contact list in a database, for instance, I want us to be able to carefully design a table or tables that makes sense, not necessarily some strange abstracted something produced by a persistor class. I don't know - too much to figure out here. However, maybe here is a plan. Maybe I am taking the persistor idea too far in my brain. Maybe instead of providing the COMPLETE storage backends, a persistor service would simply provide "helper" modules for building persistance stuff for other services. For instance, the "DB Contacts Storage" module would use the "DB Persistor". I don't know, that probably doesn't make sense. Ah, here is another take on it. Instead of a generic persistor service, maybe Persistence would be a service CATEGORY. Hehe, now that I look, that is actually what you had up above. But is it what you meant! :) Maybe we have a "Database Persistence" service, and a "XML File Persistence" service, etc. That would allow us to decide to store anywhere we like and then just build the modules on top of the various persistence services. Argh! But, on the other hand, having a "general" purpose persistence service is TOO GOOD because then it allows for storage ANYWHERE without having to code and recode modules. Maybe this is really all about carefully designing the persistence service itself to require some variety of a schema from the service/module that wanted to use it. That would allow us to automagically translate that into a REAL table format when it came to that, or an XML doc type, or whatnot. Hmmnn... > And Paul - > NO, I reread what you wrote, and I see it: > >> The Contacts service category would have the Person, Group, >> etc, etc classes in it that formed the guts of Contacts >> management. Then, Contacts Storage would (obviously) be a >> service to frontend databases, ldap, or whatever. >> And Contacts Export would provide different export >> formats for a contact - vCard, etc. > > So yes, the Contacts Service Category WOULD have those classes > that provide the "core" behavior for the Address book. Yeah. I > like it. I'll let it ferment a little longer - and try to get > this all together and pretty-like this weekend. > > OK. > More comments. > Keep 'em coming. > > and Paul, ICQ me when you get a chance, please? =) Cool. Sure. -- Paul Joseph Thompson cap...@sq... AIM/Yahoo/MSN IM: Captain Bunzo ICQ Number: 38801719 |
From: Erin S. <si...@ha...> - 2002-09-19 18:08:49
|
Paul Joseph Thompson said: >> Second: >> If we start with Paul's structure example: >>> >>> NEW SERVICES STRUCTURE: >>> + Configuration >>> * Contacts >>> + Contacts Export >>> + Contacts Storage >>> * Message >>> + Message Source >>> + Message Delivery >>> + Logging >>> + Authentication >>> + Calender >> >> I would change it to: >> + Configuration >> * Contacts >> + Contacts Import/Export >> - Uses a format >> - Uses a Persistor >> + Contact List >> - Typical add/remove etc. here >> - Uses a format >> - Uses a persistor >> + Contact Format >> - vCard >> - super-stripped-down-basic >> - SM unique format (per Simon's research) >> - possibly custom by site maintainer >> * Message >> + Message Source >> + Message Delivery >> + Logging >> + Authentication >> + Calender >> * Persistence (Storage, whatever) >> + FlatFile >> + MySQL >> + PostGRE >> + .... > > Hmmnn. A lot to think about, I think. A couple comments. > > > FIRST, just to make sure we are all on the same page here, the > research Simon is doing will likely produce the list of fields that we > decide to store in the Contact List itself, so really has more to do > with the "Contacts List" service. > > In fact, now that I think about it, "SM unique format" really doesn't > belong, unless we code something up to be a way to export/import the > addressbook ourselves. Probably a bad idea, though, as we would be much > better off finding some sort of standard out there. Well, there are a lot of different addressbooks that do all of their import/export via plain old CSV files.. And, if we decided on a super/subset or Contact information, that CSV could be mapped in your import/export appropriately. Maybe we should split the formats (Contact List Schemas, Import/Export Formats), and we can make Marc happy by providing a vCard impl that happens to fit both bills. I'll have to chew that one some more. I intended the SM custom and stripped-down basic formats as more of List Schemas anyhow. So.. maybe that's the way to go. ?! > > SECOND, I am a little - no a LOT - nervous about the persistor idea. On > one hand, it is a GREAT idea with SO FREAKING MUCH potential that I > don't know what to say. > :-P <snip> > > However, maybe here is a plan. Maybe I am taking the persistor idea too > far in my brain. Maybe instead of providing the COMPLETE storage > backends, a persistor service would simply provide "helper" modules for > building persistance stuff for other services. > Getting close.. <snip> > > Maybe we have a "Database Persistence" service, and a "XML File > Persistence" service, etc. That would allow us to decide to store > anywhere we like and then just build the modules on top of the various > persistence services. > > Argh! But, on the other hand, having a "general" purpose persistence > service is TOO GOOD because then it allows for storage ANYWHERE > without having to code and recode modules. > > Maybe this is really all about carefully designing the persistence > service itself to require some variety of a schema from the > service/module that wanted to use it. That would allow us to > automagically translate that into a REAL table format when it came to > that, or an XML doc type, or whatnot. > By George! I think he's got it. Yes. his last is what I was meaning. If we have some general way to ask the Persistor: "I want this information based on this criteria", then the Persistor should know how to translate that into the appropriate query/lookup and go do it. Config info should also be passed, which would contain the appropriate information to talking to whatever backend (filename, or mysql connect stuff).. OR, perhaps we cache in the session configured persistor instances? I like this better. (All things that go to the same MySQL table would end up secretly using the same Persistor instance which may already have opened a connection so we don't have to do that again.. and all things that go to the same file would All end up with this other one, which means the values would already be cached... and.. ) Whatever. Erin (sizzle) -- 'Waste of a good apple.' ~Samwise Gamgee ICQ: 38670353 |
From: Marc G. K. <ma...@it...> - 2002-09-19 18:34:05
|
Erin Schnabel zei: > Paul Joseph Thompson said: >> In fact, now that I think about it, "SM unique format" really doesn't >> belong, unless we code something up to be a way to export/import the >> addressbook ourselves. Probably a bad idea, though, as we would be much >> better off finding some sort of standard out there. > > Well, there are a lot of different addressbooks that do all of their > import/export via plain old CSV files.. And, if we decided on a > super/subset or Contact information, that CSV could be mapped in your > import/export appropriately. Whoops, didn't thought about csv import export. Basicly import/export are backend modules which are responsable for the translation between the internal SM addressbook format to an external format whatever that may be. The import/export module In SM should be nothing more then a class which can load an backend which take care of the translation. Provide the correct architecture and you don't have to worry about the different import/export formats. > > Maybe we should split the formats (Contact List Schemas, Import/Export > Formats), and we can make Marc happy by providing a vCard impl that > happens to fit both bills. I'll have to chew that one some more. I > intended the SM custom and stripped-down basic formats as more of List > Schemas anyhow. So.. maybe that's the way to go. ?! You don't have to make me Happy :-) . I only want you to read the vCard RFC's. If you have done that we can continue this discussion and choose what's best. Marc Groot Koerkamp. |
From: Simon T. <tur...@nt...> - 2002-09-19 19:41:59
|
Guys, guys. Give me the weekend to knuckle down to some research on this an then at least we can have a (semi) informed discussion. I'll post what I've found on (my (GMT+1)) Monday morning. I'll try and put together what should be a reasonably proper report. All the best, Simon ----- Original Message ----- From: "Marc Groot Koerkamp" <ma...@it...> To: <squ...@li...> Sent: Thursday, September 19, 2002 7:32 PM Subject: Re: [SM-DEVEL] Development plans > Erin Schnabel zei: > > Paul Joseph Thompson said: > >> In fact, now that I think about it, "SM unique format" really doesn't > >> belong, unless we code something up to be a way to export/import the > >> addressbook ourselves. Probably a bad idea, though, as we would be much > >> better off finding some sort of standard out there. > > > > Well, there are a lot of different addressbooks that do all of their > > import/export via plain old CSV files.. And, if we decided on a > > super/subset or Contact information, that CSV could be mapped in your > > import/export appropriately. > Whoops, didn't thought about csv import export. > Basicly import/export are backend modules which are responsable for the > translation between the internal SM addressbook format to an external format > whatever that may be. > > The import/export module In SM should be nothing more then a class which can > load an backend which take care of the translation. > Provide the correct architecture and you don't have to worry about the > different import/export formats. > > > > > Maybe we should split the formats (Contact List Schemas, Import/Export > > Formats), and we can make Marc happy by providing a vCard impl that > > happens to fit both bills. I'll have to chew that one some more. I > > intended the SM custom and stripped-down basic formats as more of List > > Schemas anyhow. So.. maybe that's the way to go. ?! > > You don't have to make me Happy :-) . I only want you to read the vCard RFC's. > If you have done that we can continue this discussion and choose what's best. > > Marc Groot Koerkamp. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > http://squirrelmail.org/cvs > |
From: Alvaro Munoz-A. Mtnz. <alv...@ay...> - 2002-09-15 18:09:40
|
Hi all, Yes a roadmap is helpful, so people can make an idea where their versions are in the whole software life, an where the project is heading in time, where the branches start and go, also some milestones control is nice, once again I point out to Mozilla's stuff to get ideas :) http://www.mozilla.org/roadmap.html Regards Alvaro Simon Turvey wrote: > Is there a development plan/roadmap anywhere. I'm trying to get my head > around where Squirrelmail is going so I can work out where I can be of > assistance. > > Cheers, > Simon > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > http://squirrelmail.org/cvs > > |
From: Marc G. K. <ma...@it...> - 2002-09-16 08:38:06
|
> So, now that the dev list is again talking about dev, I have a few things: > > ONE - The DEV CVS data_dir fix: > Has ANYONE tried the fix to conf.pl I posted yet? I mean, having the > dev CVS broken with people unable to log in seemed pretty serious, > but I haven't heard anything about anyone testing my fix. YEESH. I > would like a LITTLE feedback before I go putting it in CVS (since > people are all bent about CVS right now anyway) so PLEASE PLEASE TEST > IT! Send a note to me if you need the tarball again (not that it's > big, just that Idon't want to post it AGAIN). :-P > > TWO - Zookeeper: > I think Paul should also clarify what effort will go towards getting > things ready for ZooKeeper, and what intermediate steps should be > made in the SquirrelMail development stream to keep it evolving. > Paul and I have talked about what he sees coming, and I think it's up > to him to get all his thoughts in a format we can work with. > > THREE - The new Addressbook: > I've been working (with Paul's blessing) on the beginnings of a design > for the new Addressbook that will conform to the ZooKeeper model. To > be honest, having a vCard interface was not on my list as a core part > of the new Addressbook.. It should certainly support and interact with > vCards, but I don't see that being a core requirement - should be an > add-on module, in my opinion. Probably the zookeeper model needs some more clarification on the devel list. I did have a look at zookeeper once but I'm not sure it's the answer to SM and the making things more dynamic approach. Maybe that's because of lack of knowledge about zookeeper on my site and that's why I like t see an in depth discussion about zookeeper. Personally I like the use of extended classes because I think they are very dynamic. I don't think the zookeeper architecture make use of it. > I do have the following items as a poll for your feedback (I'll get > the design together and will post it - hopefully in CVS within > whatever area Paul has decided is appropriate so that everyone can > hack it to bits): > > 1. I think we want (at the LEAST): > Support for individual addresses > - adding from email to/from/cc fields > - using nicknames RFC2822 talks about a personal name, mailbox name and hostname. The nickname you are talking about, is that the personal name? > Support for address groups > - basically nickname for multiple people Cool. > Standard address book features > - search/sort/list > - autocomplete in To/CC/BCC fields? > - add/remove > - import/export > You were talking about vCard as a module. I think that's the wrong approach. vCard should be the heart and the addresbook implementations are the modules. Especially when you're talking about import/export it's better to have fully support for vCard because I think that's the standard and following RFC standards from the beginning is very important for portabillity! RFC rules :-) > 2. Address information: > Currently thinking of three levels of contact info > Basic - Full Name, Nickname, email > Business - Basic + > Business-type telephone/address information > Family - Basic + > Family-oriented information (addr + anniversary/birthday) > There are two ways to use these levels, either > as attributes of the entire address book (what kind of site is it) > OR as an attribute of the address itself (since we only need > the basic elements to address mail, having a blob containing > the rest of the information would hardly hurt.. something to chew > on in any case). > Again vCard support it. This is simply a filter on the available vCard fields. > 3. Address books - only one? > I think we need support for multiple address books. > At LEAST, we have the personal address books. > I think we should offer (within the Zookeeper structure) > support for group address books (common for groups > of users - a global address book would be a special case > where the group of users happens to include everybody). > There will have to be some determination for how you > decide who can or can't edit addresses in group address > books, but I think that's a long way off yet. Totally aggreed about multiple addresbook. It should be possible to support N addresbooks (Yes I like dynamic implementations :-) ) If the main interface (vCard) is of good design all 3 suggestions you made can be implemented by simply writing addresbook modules which can hook into SM. First step is writing the all supporting base class next step is writing the different addresbook implementations in whatever form you would like. > > SO, I'd like some opinions. > Common elements that every address book entry should have? Do you think > having different levels is stupid? If there were personal and group > address books, should the listings be intermingled or separate? Seperate. > > Some of that is sort of low-level, especially for this early in the > design, but I wanted to throw it in there just to see what you guys > thought. The address book and the Calendar are the two things I think need > the most work, so I volunteered to get the Address Book re-written. You should talk with Stefan Sells. He already started some development regarding vCard and the import/export to pda's. Maybe you can work together on it. > > Let me know what you think. > And darnit! Try out that data_dir fix! Just tried and when the data_dir = ../data it still doesn't work :-( (with the message_details plugin) > > Erin > (sizzle) > > -- > 'Waste of a good apple.' ~Samwise Gamgee > ICQ: 38670353 > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > http://squirrelmail.org/cvs > |
From: Rick C. <ri...@sq...> - 2002-09-16 13:49:40
|
Keep in mind also that we are not limited to vCard implementation. It might be wise for use to support all vCard fields, PLUS some extra logical fields. One of my recent projects at my old company was creating and implementing a "standard" addressbook format that took the best fields from the vCard spec, the RFC address proposed spec, and a couple other logical fields. It really depends on how complete and detailed an addressbook we want to have. Let's not handcuff ourselves to a limited spec if we can support it *and* other good stuff... like a vCard+ or something. -Rick Marc Groot Koerkamp said: >> So, now that the dev list is again talking about dev, I have a few >> things: >> >> ONE - The DEV CVS data_dir fix: >> Has ANYONE tried the fix to conf.pl I posted yet? I mean, having >> the >> dev CVS broken with people unable to log in seemed pretty serious, but >> I haven't heard anything about anyone testing my fix. YEESH. I would >> like a LITTLE feedback before I go putting it in CVS (since people are >> all bent about CVS right now anyway) so PLEASE PLEASE TEST IT! Send a >> note to me if you need the tarball again (not that it's big, just that >> Idon't want to post it AGAIN). :-P >> >> TWO - Zookeeper: >> I think Paul should also clarify what effort will go towards >> getting >> things ready for ZooKeeper, and what intermediate steps should be made >> in the SquirrelMail development stream to keep it evolving. Paul and I >> have talked about what he sees coming, and I think it's up to him to >> get all his thoughts in a format we can work with. >> >> THREE - The new Addressbook: >> I've been working (with Paul's blessing) on the beginnings of a >> design >> for the new Addressbook that will conform to the ZooKeeper model. To >> be honest, having a vCard interface was not on my list as a core part >> of the new Addressbook.. It should certainly support and interact with >> vCards, but I don't see that being a core requirement - should be an >> add-on module, in my opinion. > Probably the zookeeper model needs some more clarification on the devel > list. I did have a look at zookeeper once but I'm not sure it's the > answer to SM and the making things more dynamic approach. Maybe that's > because of lack of knowledge about zookeeper on my site and that's why I > like t see an in depth discussion about zookeeper. > Personally I like the use of extended classes because I think they are > very dynamic. I don't think the zookeeper architecture make use of it. > > >> I do have the following items as a poll for your feedback (I'll >> get >> the design together and will post it - hopefully in CVS within >> whatever area Paul has decided is appropriate so that everyone can >> hack it to bits): >> >> 1. I think we want (at the LEAST): >> Support for individual addresses >> - adding from email to/from/cc fields >> - using nicknames > RFC2822 talks about a personal name, mailbox name and hostname. > The nickname you are talking about, is that the personal name? >> Support for address groups >> - basically nickname for multiple people > Cool. >> Standard address book features >> - search/sort/list >> - autocomplete in To/CC/BCC fields? >> - add/remove >> - import/export >> > You were talking about vCard as a module. I think that's the wrong > approach. vCard should be the heart and the addresbook implementations > are the modules. Especially when you're talking about import/export it's > better to have fully support for vCard because I think that's the > standard and following RFC standards from the beginning is very > important for portabillity! RFC rules :-) > >> 2. Address information: >> Currently thinking of three levels of contact info >> Basic - Full Name, Nickname, email >> Business - Basic + >> Business-type telephone/address information >> Family - Basic + >> Family-oriented information (addr + >> anniversary/birthday) >> There are two ways to use these levels, either >> as attributes of the entire address book (what kind of site is it) >> OR as an attribute of the address itself (since we only need the >> basic elements to address mail, having a blob containing the rest >> of the information would hardly hurt.. something to chew on in any >> case). >> > Again vCard support it. This is simply a filter on the available vCard > fields. > >> 3. Address books - only one? >> I think we need support for multiple address books. >> At LEAST, we have the personal address books. >> I think we should offer (within the Zookeeper structure) >> support for group address books (common for groups >> of users - a global address book would be a special case >> where the group of users happens to include everybody). >> There will have to be some determination for how you >> decide who can or can't edit addresses in group address >> books, but I think that's a long way off yet. > Totally aggreed about multiple addresbook. It should be possible to > support N addresbooks (Yes I like dynamic implementations :-) ) > If the main interface (vCard) is of good design all 3 suggestions you > made can be implemented by simply writing addresbook modules which can > hook into SM. First step is writing the all supporting base class next > step is writing the different addresbook implementations in whatever > form you would like. >> >> SO, I'd like some opinions. >> Common elements that every address book entry should have? Do you >> think having different levels is stupid? If there were personal and >> group address books, should the listings be intermingled or separate? > Seperate. > >> >> Some of that is sort of low-level, especially for this early in the >> design, but I wanted to throw it in there just to see what you guys >> thought. The address book and the Calendar are the two things I think >> need the most work, so I volunteered to get the Address Book >> re-written. > You should talk with Stefan Sells. He already started some development > regarding vCard and the import/export to pda's. Maybe you can work > together on it. > > >> >> Let me know what you think. >> And darnit! Try out that data_dir fix! > > Just tried and when the data_dir = ../data it still doesn't work :-( > (with the message_details plugin) > >> >> Erin >> (sizzle) >> >> -- >> 'Waste of a good apple.' ~Samwise Gamgee >> ICQ: 38670353 >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> -- >> squirrelmail-devel mailing list >> List Address: squ...@li... >> List Info: >> https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel >> http://squirrelmail.org/cvs >> > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > -- > squirrelmail-devel mailing list > List Address: squ...@li... > List Info: > https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel > http://squirrelmail.org/cvs |
From: Paul J. T. <cap...@sq...> - 2002-09-16 22:54:44
|
Bad when you reply to your own message, eh? I just wanted to add a zookeeper comment here. I would suggest that we develop at least 2 different services for the addressbook stuff we need here. Service #1 - Contacts This will be the CORE addressbook service. ALL this is about is providing a modular way to access addressbook information (peopleand groups). The backends can be databases, text files, etc, whatever. Service #2 - Contact Export This will be a supplemental service and provide various modules for exporting addressbook information in. One module would export as vCard, the next as something else, etc. Hmmnn. Maybe more services here. The reason that Contacts export should NOT be set on top of Contacts is to isolate the dependancy between the way an addressbook is stored and the way it is exported. Of course, they would share the same central addressbook classes, for the most part. -- Paul Joseph Thompson cap...@sq... AIM/Yahoo/MSN IM: Captain Bunzo ICQ Number: 38801719 |
From: Erin S. <si...@ha...> - 2002-09-16 23:32:27
|
Paul Joseph Thompson said: > Bad when you reply to your own message, eh? > > I just wanted to add a zookeeper comment here. I would suggest that we > develop at least 2 different services for the addressbook stuff we need > here. > ... > > Hmmnn. Maybe more services here. The reason that Contacts export > should NOT be set on top of Contacts is to isolate the dependancy > between the way an addressbook is stored and the way it is exported. > > Of course, they would share the same central addressbook classes, for > the most part. > > Dear Over-taxed team leader: I will search the wiki for a suitible location to post the new Addressbook design and associated research materials. However: You asked me to develop a design. I am an OO design/developer - I know how to do this stuff. So let me do it. If you're short on cycles, then save yourself some brain-activity by at least wait until those you've assigned to design things can post something for you to comment on before you do their job for them. ;) As I said in the original post, I was requesting comments, to see where hang-ups were, so that the design could be appropriately flexible where necessary. I like your research idea (especially since we have some .. avid proponents of certain formats.. hint hint, Marc ;) ) and would welcome a format where we can do some serious and straightforward comparison. But I am quite capable of creating a design that even you will have to like. THPPT :-P Erin (sizzle) -- 'Waste of a good apple.' ~Samwise Gamgee ICQ: 38670353 |
From: Paul J. T. <cap...@sq...> - 2002-09-16 23:36:04
|
Simon, Thanks for stepping up to the plate, Simon! Make sure to keep in good communication with Erin Schnaebal (sp?) on this one. You can see her messages on the development list. She is the developer I have stamped as OFFICIALLY in charge of this. Please try to keep the SquirrelMail development list CCed or as the MAIN TO for your plans, progress, etc, on the addressbook research, progress, etc. That will enable us all to stay both as up to date and involved as possible. Thanks, Paul Thompson >> We DON'T want to base the addressbook explicitly on vCard. Rather, >> vCard would be an export format or whatnot, not the core. >> >> One more assignment for WHOEVER wants to take it: I would appreciate >> VERY HIGHLY if someone would take the time to research a handful of >> the most common addressbook specs and present some sort of a report to >> the development team. This will help us decide what we want to >> include. > > Right, I'll take this on then. > >> First, I would like to ask people for a list of what they think are >> the most logical candidates for consideration on this list. Here is a >> starting suggestion list. Please reply-to-list and add to it: >> >> 1. vCard >> 2. Outlook (sorry, but it is a standard of sorts) >> 3. Lotus Notes (Notes users out there?) >> 4. Evolution > > Good idea. If people could CC me explicitly too then that would be handy. > > Simon > > -- Paul Joseph Thompson cap...@sq... AIM/Yahoo/MSN IM: Captain Bunzo ICQ Number: 38801719 |
From: Erin S. <si...@ha...> - 2002-09-17 14:47:44
|
Paul Joseph Thompson said: > Simon, > > Thanks for stepping up to the plate, Simon! Make sure to keep in good > communication with Erin Schnaebal (sp?) on this one. You can see her > messages on the development list. She is the developer I have stamped as > OFFICIALLY in charge of this. > > Please try to keep the SquirrelMail development list CCed or as the MAIN > TO for your plans, progress, etc, on the addressbook research, progress, > etc. That will enable us all to stay both as up to date and involved as > possible. > > Thanks, > Paul Thompson > >> >> Good idea. If people could CC me explicitly too then that would be > handy. >> >> Simon >> OH! Paul: it's Schnabel. It's a german enough name without adding any more letters to it.. :-P Simon: Hoo-ah! Glad you opted to do this.. LOL I will coordinate with Paul to get some kind of area set up in the wiki so we can get to work ;) Erin (sizzle) -- 'Waste of a good apple.' ~Samwise Gamgee ICQ: 38670353 |