Hi All, I've been lurking on this thread and keeping my mouth shut. It seems most of the interesting stuff has been fleshed out so I'd like to add my lowly two cents [which became about 15 dollars... sorry this is so long] Coming from an academic environment with very little commercial software experience I'd like to comment on a few things. 1. I like the fact that Ximian people are aware that the future needs of PIM is changing and is in fact a moving target. Today we use mostly Email/IM, Contacts and the Calendar for communication with others. Who knows what will be used in 20 years. I think all of these will be around in some for or another but it's definitely going to change. 2. I also like that someone has challenged the mentality that Outlook, Groupwise, etc. where correct in their monolithic program PIM solutions. I believe that each application _should_ be split into their own - that being said I don't think they should necessary be their own executables. It should likely not be viewable to the user as separate components but to us, the programmers it should be. Information hiding is key. 2.1 Modularity is the separation of concern and information hiding. A should not know how B does it's job. Why should the calendar program need to know how a contact record is stored in the Contact DB? It shouldn't, it calls the interface with the contacts ID and it is returned the record in the agreed upon way based on the programming interface Specs. Some people call this "contract programing" I believe. If an email has a request of a meeting it passes that to the calendar component through the proper interface. The mailer may need to inspect the request to parse it into the proper form for the mailer/calendar interface, but that is a design decision of who should do the parsing. 2.2 Modularity is hard. You need good foresight, good planning and you need to separate out the modules that are likely to change from your core stuff that is stable and rock solid (email reading,pop,imap should always be just that). This way you don't upset things when a program changes. From what I've seen, you want everything to be as loosely connected as possible across the minimum number of interfaces. But of course this is very hard to do, especially if you already have a code base that was not planned with this in mind (I have no idea if Evo was or not so I cannot comment on that). 2.3 Why should we throw out the work that has already been done. Is refactoring the code going to allow you to create good modular design. The short answer is: Probably not, but then again even with modular design in mind you can still come up with a design fit for the bit bucket. 3 Why should we separate the systems? Don't they all depend on each other? Of course they do, but the magic of modularity is in the "programming interfaces" [very different from "user interfaces"]. If you can standardize your interface and make it stable and publicly available then you put the power into "external developers" hands to write programs that they can drop into Evolution and will run just fine. The key thing here is that the programmers know about the divide, but the users do not. The interface (the programming one, the GUI should be able to change depending on the module used) remains the same no matter which module I choose for the contact list if it's Mozilla's (which would be a modified version of their current mailer project), Evolution's or one I wrote on my own. They will all work. It's often demonstrated by looking at cars. You can change tires, lights, even the engine etc. to get a different vehicle. This is all done without having to rip the car completely apart and starting from scratch. Or you can add decals and new paint without having to rip apart the insides, although some reconstructive work may need to be done. That analogy breaks down of course because you can't put in a diesel without changing a lot of other parts that depend on it. It's possible, but the dependencies need to be flushed out and those parts also changed. You just need to know what you are doing - which is the hard part. Another good part about modularization is that you don't have to know the entire code base. You know your local module only and you depend on the interface documentation to be correct for other modules. You assign people to take care of a specific module and that is what they do. Someone becomes the master of the contacts, someone the master of the mail reader, and someone the master of the calendar and so on. You can even go into finer detail if required. Then of course you need the head honcho (Architect) to get each component to play nicely with each other. Anyway, that's pretty much the nutshell theory I've been taught. Is it going to work in real life on a currently working code base. I'd like to think so but I have my doubts. From what I've read it seems evo is going that way with the components but until I can rip out the calendar component and stick in a different one it won't really be modular to me. It's a lot of work, and I think it's the right thing to do but businesses and people don't always do the "right thing ^TM". I'm debating to click send or exit. Cheers, Still Green in "real world" Software - Chris Ness -- Software Engineering IV, McMaster University PGP Public Key: http://nesser.org/pgp-key/ 13:23:52 up 4:15, 5 users, load average: 0.00, 0.14, 0.22 Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
Attachment:
signature.asc
Description: This is a digitally signed message part