[Dev] Re: [Design] Rethinking scalability as a goal

David Neeley dbneeley at oddpost.com
Thu Nov 14 16:22:05 PST 2002

Two issues of scalability strike me offhand. 
First, because of the continuing lack of work for unemployed technical writers, I have just accepted a position with AFLAC insurance (for American audience, the ones with the hilarious duck commercials). 
I say that because I am looking at PIMs from the standpoint of integrating processes such as sales workflows into a PIM. Many people call this "Customer Relationship Management" when it also integrates with backend processes. 
However, there are many other people besides sales and marketing types who have recurring sets of processes--perhaps tasks that are repeated, each one with the same basic constituent parts. Thus, this is one area of acute interest. If we can expose our information storage to remote backend systems in some kind of systematic way, then we may in fact have an invaluable front end for enterprises of all sorts. Again, I believe that XML data storage may empower this interprocess and intersystem communication in very meaningful ways. 
Another implication of the idea of "scalability" lies in the needs of many people who never wish to edit or delete anything. As email messages alone begin to amass in quantities best measured in the tens of thousands, it becomes a definite issue each time a simple search must be done. That is why I suggested the notion of being able to set time limits on individual items, bringing them into a schedule for reduction of priority with the passage of time. If the information database is divided in such a way that messages that become older than some date the user sets, or below some importance threshold determined directly by the user or indirectly via one of these staleness algorhithms, might be moved into a longer-term storage environment, then search speed and quality of results is kept much more manageable. 

-----Original Message----- 

One area we are now rethinking, based on input from the mailing lists and 
other sources, is whether also build Chandler from the outset to support 
large organizations, not just small-to-medium ones. Based on further 
internal brainstorming, it seems less difficult than what we had 
imagined. It also looks fairly likely we will be getting some world-class 
technical help on a volunteer basis. 

Note that such support, which would involve some kind of server, does not 
mean we are going to focus on large enterprises as customers. Scalability 
is but one of a number of requirements for a true enterprise solution. It 
does mean that, if we go in this direction, Chandler could provide a 
solution for a university environment. 

I'm posting this now, before a commitment has been made, to get reaction 
and feedback. 

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

Open Source Applications Foundation "Design" mailing list 

More information about the Dev mailing list