Since the outset, we've intended that Chandler be useable by groups without requiring a server. Sharing calendars among a small group should not require the considerable effort and expense of purchasing and maintaining an Exchange server. Instead, a peer-to-peer protocol can be used to coordinate the flow of information. In this way, Chandler will enable small groups of non-technical users to be far more self-sufficient than they would in a situation which requires special server hardware and software, the administration of which is outside the expertise of the users themselves.
In general, we have emphasized a style of usage in Chandler that can be called decentralized, in which there is no central authority or controller of resources, and in which peer-to-peer exchange is the dominant means of communication.
I must confess to a long-standing personal disposition in favor of decentralization. Ten years ago I was (naively) holding out hope in Wired magazine that a decentralized Internet would lead the way to a revival of Jeffersonian democracy. This obviously did not happen, and I let go of my na�ve techno-determinism. However, my affection for the non-hierarchical remained strong, something which can clearly be seen in Chandler's original conception.
What has become crystal clear though is that we must also support more centralized approaches if we are to gain the organizational adoption crucial to having the impact we hope to have.
A couple of months ago we were invited by a major foundation to meet with representatives of the computing services organizations of a group of major research universities. The agenda was set up to explore whether Chandler's calendaring capabilities would address a pressing need felt by the group. Our meeting led in turn to a more general discussion of scenarios for Chandler on campus.
Universities operate in a partially centralized fashion with respect to their computing and networking infrastructure. Typically, authentication and authorization functions depend on centrally maintained computing infrastructure like Kerberos and LDAP directories. Storage in the form of high-capacity IMAP servers for email are also important elements on most large campuses.
As we continued to discuss how to adapt Chandler to work in a university environment, it became clear that any flavor of organizational deployment of Chandler, whether campus or corporate, was going to run into the issue of integration and interoperation with one or another set of centralized resources. Without a clear technical strategy for penetrating organizations, Chandler's impact would be blunted, if not marginalized. While many of Chander's advocates (including most of the OSAF staff) are personally disposed toward a decentralized style of operation, the drive to be pragmatic about accomplishing our mission required us to embrace a mode of Chandler suitable for organizational deployment, one which embraces relevant uses of external, centralized infrastructure. This is to be done in conjunction with, not as a substitute for a decentralized, P2P approach. Chandler, as an integrated whole, must support both.
Posted by mitch@osafoundation.org at February 02, 2003 12:18 PMRegards the 'central' versus 'de-central' argument, it occurs to me that this is much the same as the argument over moderated versus un-moderated discussion groups---obviously un-moderated is the ideal, but in general this results in too much 'noise' in the channel. Just a thought...
--hsm
Posted by: Hugh S. Myers at February 3, 2003 05:39 AM
I'd advocate an even further broadening of the centralized vs decentralized thinking. It's not uncommon in academia to need an infrastructure that allows for campus-wide sharing where individual units (schools, colleges, institutes) require control over their own resources and people. This could be P2P, where the peers are functional units instead of individuals, or it could be a centralized infrastructure with delegated administration.
This is a challenge not often met well by creators of software. It would be a worthy one for Chandler to accept.
Posted by: MaryBeth Stuenkel at February 3, 2003 06:07 AM
There need be no conflict between centralized vs. decentralized processing given a design that recognizes up-front that both will exist.
Scheduling issues present a good example here. For instance, I may wish to schedule a meeting with four people. Two of them use a centralized server and two use no such server but do have clients that support scheduling. To make this work, my client (or server) only needs to be able to have some metadata or profile information that tells me, for each user, how to schedule meetings with them. In the case given, I would send three messages to "check schedules." One message would go to the centralized server to cover the two users there and a message would be sent to each of the independent users. This approach implies that Chandler would contain the necessary code to recognize and deal with schedule conflicts for "split" requests as well as be able to delegate some functions to remote servers where possible. This should not introduce significantly more complexity than would be needed to serve the needs of a community where there were no servers. The only problem with this approach is the same that exists in P2P systems generally and that is one of being able to perform strict transactions...
If Chandler implements an API and/or protocol for doing such split scheduling, then it becomes a simple matter for indepedent software developers to write gateway modules between specific scheduling servers and the Chandler system. If designed properly, these API's could hide from Chandler the fact that there were any significant differences between scheduling systems.
By abstracting out scheduling, email delivery, instant messaging, etc. it should be possible for Chandler to isolate itself in general from concerns about the topology of the network and whether some users are being served by shared resources while others are not. (Note: The one exception here is that it would make sense for Chandler to be able to recognize when multiple people are being served by a single resource and, if that resource supports it, "batch" or combine requests for service from that resource.)
Chandler can, via design, isolate itself from concern for whether services are centralized or decentralized. It need only be concerned with its own view of the "virtual" network.
bob wyman
Posted by: Bob Wyman at February 3, 2003 07:46 AM
"Market driven" is Vision riven.
Posted by: Joe O'Laughlin at February 3, 2003 09:00 AM
Your arguments for needing a modicum of integration with a central authentication/authorization infrastructure sounds a lot like what I recall reading about the development of Groove. While initially a pure P2P orientation emerged, I believe that some form of central "control elements" had to be accommodated to meet the requirements of larger organizations. I'm sure that this is a lesson that won't be lost on the Chandler team.
Posted by: Bob Monsour at February 3, 2003 09:03 AM
I think you are correct in your decision to address both "fronts." Though I don't know the technical challenges to doing so, ideally Chandler will not offer either/or but rather both/and. For example, I haven't looked at recent versions of Outlook, but in Outlook 2000, if it is being used in Corporate or Workgroup mode (for use with an Exchange server) then you cannot connect with an IMAP server. It would be good if Chandler could avoid that kind of modal behavior while addressing the centralized and decentralized issues.
Posted by: Paul Johnson at February 3, 2003 10:21 AM
There is a relationship between the rapidly evolving message and metadata standards for web services and how one can harmonize organizational and individual needs. Negotiation and communication between existing server-based infrastructures and individual free-standing clients should be based on using these standards. Using the correct architecture, the location (or locus of control) of an 'individual' can effectively be abstracted away. Of course this will not happen overnight, but it clearly provides both a migration and co-existance path.
Posted by: Peter Miller at February 3, 2003 12:32 PM
I hope that this change in thinking does not mark the end of the Chandler dream. Some applications like Napster took off because of compulsive features - I was hoping that Chandler would become the Napster in the PIM space. No university student is bound to use Chandler, just because his university struck a distribution deal with OSAF. Even MS is aware of this fact and they pay universities to use their software.
Adding compatibility with existing calender solutions is area where companies like Ximian and Bynari have already made much headway - It's not clear how you propose to do a better job ?
Posted by: S.Ramaswamy at February 3, 2003 04:57 PM
(I have two friends who are both IT directors at large universities, so this comment is informed only by discussions with them, not personal experience.)
The pressure to be more centralized or decentralized is a central issue of IT administration. Periodic "consolodations" or "centralization" occurs when the campus systems become too disparate and support and maintenance becomes unmanageable, particularly after layoffs from state cutbacks.
The centralization is painful, but serves the purpose of making all systems more uniform and better supported. Over time, individual groups' needs are not met by the "defined" solution, and the groups take it upon themselves to "innovate" their local IT environment.
Which, over time, leads to needing another "centralization."
The crux seems to be, can Chandler provide these different groups the flexibility of "decentralized control" while integrating cleanly with the uniform IT environment and not causing degredation of support. I'm not sure it ever can, but it can certainly do better if it thinks about the problems.
Posted by: Jim Jarrett at February 5, 2003 06:03 AM
Communication amongst people is essentially peer to peer. There is no central entity that we must make use of to communicate with another person. However, there is always an instrument that is used to perform the communication with another person - or for any communication. When I get pinched, my finger doesn't just tell my brain it's being pinched, it relies on my central nervous system which acts as a transport between my brain and my ability to feel. Being able to see, hear, etc... all are mechanisms which use certain instruments to communicate to and from the brain. Throughout the process, the brain is the central entity of the body. If I touch something that is very hot, the cells in my finger don't instruct my muscle to retract, my brain does. Aside from a person's soul/meaning/essence/etc (<-- outside of the scope of this ;), a human is scientifically centralized in how it operates, and communicates in a peer to peer manner.
I believe it would be wise to create Chandler in a decentralized fashion for communications, but enable it to operate in a centralized system. Not that you would want to redesign the centralized system, but instead, use it as an instrument, method, tool, or path to communicate.
Posted by: Alex at February 5, 2003 01:34 PM
Will the centralized and decentralized components of Chandler share a common open-source license, or will they be licensed differently?
Is guidance available on the nature of the "Chandler Public License" (or equivalent existing license to be adopted by Chandler)?
License partitioning can decouple contributions by open-source developers on either side of the P2P2C boundary, if there arise conflicting requirements that cannot be mediated within the scope of Chandler development.
The new strategy delegates Chandler's relative weighting of Centralized/P2P to external (centralized and P2P) influences. A stable composition of these conflicting influences would owe more to licensing than to technical architecture.
Posted by: Rich Persaud at February 8, 2003 12:09 PM
Another way to look at the debate is to frame it in terms of replicated vs singular. P2P shared information (lots of communication fits into this domain, for example a voice conversation) is essentially replicated, which implies that a distributed model applies. For other types of information a singular instance is more appropriate (for example, my current status, or my current address). In these cases centralizaton is viable (although possibly not necessary).
I think that it may be important to distinguish between centralization for convenience, operational cost reasons, and the like, and centralization because the information is essentially singular in nature. It may also be important to distinguish between distribution because we can, and distribution because there is no single instance of the information, and hence centralization is meaningless.
Bottom line - the model is important - good luck.
Posted by: Steve McKinnon at February 12, 2003 08:05 PM
One way to approach this issue might be to look at the way the Open Archives Initiative is doing things.
They have developed a protocol for harvesting metadata from a globally distributed group of archives.
The centralisation comes from the archives registering themselves as cooperating nodes. This allows harvesters to centralise the proffered metadata, in a manner that is entirely "opt-in" for the individuals. I think there are parallels here for Chandler in a "group" settings.
In a corporate/university setting, where you will need to enforce a bit of structure, it could be appropriate to allow the clients to be "pre-registered" as part of the body, before redistribution. In OAI terms, this would amount to setting the first part of the URI. In Chandler, perhaps all one has to do is set a top-level namespace? This process should be carried out by the people charged with rolling out the application, so one could be assured of getting some minimal level of cooperation (ie interoperation). [I'm envisaging "rollout" as making an installer available on the intranet, plus some small-group trials beforehand.] By checking the registration records, servers/harvesters can decide whether to work with or ignore a given client.
Since this software will be freely distributable, one expects that various early adopters will take it up before the decision for a full-scale rollout is taken. So one would like to be able to publish the template for registration, to bring these clients "into the fold". [Bing! This would also be useful for people moving *between* organizations that use Chandler.]
Perhaps you could use this approach to enforce new versions of a group's template - ie limit access to shared resources until you upgrade. It's unclear to me if people will continue to cooperate, particularly if there are frequent updates. I guess if the upgrade process is painless, and doesn't occur too often, they might. They won't all change at once, so that will need to be handled gracefully. Otherwise, perhaps in very top-down environments one could force updates. That seems fraught with security and privacy issues. Digital signatures might help the former (check for the same sig. that came with the previous templates one installed), but the latter seems much harder to solve. Presumably one has to tell chandler what to share, and the centralised agents will have to abide by that?
Posted by: Vince McIntyre at February 14, 2003 09:19 PM
I agree with Vince - there should be a way to use the OAI architecture, XML or some sort of interface approach that would define the communication between Chandler and central resources others could build on when it seems appropriate. Also, it is worthy of note there is a Open Source version of the Exchange server known as the Bill Workgroup Server which is also built on Python. While I think it is still necessary to work with the commercial market, this seems like a good place to start...
http://www.billworkgroup.org/billworkgroup/home
Posted by: MichaelD at February 17, 2003 10:15 AM
IMHO, the issue is really less about whether P2P or client/server architectures or approaches are better / worse. The issue is "How do you encourage viral spread among early adopters to achieve success, and then make a successful shift to an organizationally-supported application?"
It is helpful to remind us of the history of the web, of SMTP email, and other such successful technologies:
If the radical fringe is lucky enough to become the mainstream, expectations and requirements change.
P2P / distributed is good because it can be deployed by anybody on their own machine, without requiring involvement / approval from some central resource. So the radical fringe can adopt it, promote it, and make it desirable / successful broadly.
Browsers & SMTP/POP3 clients started on the desks of the radical fringe, with people using whatever server they could find. The same is happening today with instant messaging.
Then these became mainstream because they proved their value, and lo we became happy because our IT staffs deployed SMTP/POP3/WWW servers data centers it all just got "better" -- more stable, faster, backed up, integrated with corporate directory services, etc.
Then Microsoft came and provided Exchange, which gave non-guru administrators a friendly, easy way to deploy and manage these tertiary things that *support* the basic transport and use of email. SMTPD gets replaced by Exchange. Ditto web servers.
Today we see AOL/MS trying to do the same with IM infrastructure.
(Certainly there are other reasons for Outlook / Exchange success, such as tying client behaviors to the presence of Exchange in the back end, and oh that Monopoly that MS has. But my point still stands.)
So I think the Chandler team should think of this more as designing that careful interplay between the ability of Chandler to be "viral" up front by not requiring approved, centralized organizational servers, but having a fundamental awareness that organizational support may well arrive, and the more Chandler take advantage of the benefits that central IT support can provide, the more the IT staff will embrace it and ultimately promote its success.
It *could* be that, like SMTP/Jabber/..., the architecture might want to depend on having publicly available servers on the net for use by early adopters, and then companies that want to adopt can deploy and manage their own server.
Ok, I'll stop. You get the point.
---
Oh, and I can't resist saying that using P2P "only" obviously ignores the value of having information available to other "peers" when one of the peers is offline. I'd like you to be able to check my free/busy time in my schedule when my laptop is turned off. An omnipresent server is sure helpful for this....
I'm sure Mitch will remember the benefits MeetingMaker provided in this arena, and it will guide his thinking.
(BTW -- Hi, Mitch.)
Posted by: Jay Batson at February 26, 2003 06:53 AM
Your home page is coming up weird on my machine...been like this all day...
Posted by: GilbertZ at March 11, 2003 12:59 AM
I'm wondering if a distributed system that'll help people share ideas, contacts, addresses, & e-mail could also be used as a way to create (verifiable) online identities.
I've run into a system called Ryze (http://www.ryze.com) that offers a way for people to leverage social networks -- based on a system of shared personal-ryze-homepages.
The link? You could perhaps imagine a future Chandler user looking up a contact to see what contacts *that* person had, what expertise *that* person could share.
personal-centric knowledge management...
Posted by: Tom Portante at March 17, 2003 08:13 AM
Phil Agre writes eloquently about the centralized/decentralized conundrum:
http://dlis.gseis.ucla.edu/people/pagre/peer.html
Posted by: mark crane at March 28, 2003 08:41 AM
Good reading. Thanks, Mark.
Posted by: Sam at March 31, 2003 12:49 PM
The Occam's Razor thinking of peer-to-peer vs. centralized or client-server architecture prevents thinking of other modalities.
Consider mixed modalities - shades of grey - between the extremes.
There is no reason other than our own blinders that prevents approaches to this kind of problem from a different axis.
Simplistically one could have a list of peers and a list of centralized connections, each with their own rules of operation.
For the LDAP/IMAP structures you have a table of the information/rules needed to handle inbound and outbound messages. For the peered structures you have a different set of rules.
Each person in your working group would be assigned the appropriate rules and the PIM does the intermediation needed to connect across the boundaries.
This could be set up much like the intermediation tools that are used to connect disparate database structures used by different organizations. These tools are simply plug-ins between known and documented structures.
Posted by: Allen at April 25, 2003 10:25 AM
lol!
Posted by: cover letter at August 21, 2003 10:10 PM
Thanks Mark Crane the Phil Agre text is very interesting.
Posted by: Trabajo at October 1, 2003 07:55 AM
Good reading. Thanks, Mark.
Posted by: ocx at November 3, 2003 03:26 PM