Tipping the Edge

Tim O’Reilly recently talked about the evo­lu­tion of soft­ware and how all soft­ware should be net­work aware. While I gen­er­ally believe that this is true (see my Feb­ru­ary 2000 arti­cle on Hybrid com­put­ing), I’d like to make a few com­ments on Tim’s note.

Dis­cov­er­abil­ity and Security

The first assump­tion is that soft­ware should be able to con­nect auto­mat­i­cally. While this is gen­er­ally a good idea, there is a need to set up dif­fer­ent lev­els of acces­si­bil­ity. Busi­nesses gen­er­ally will want some level of con­trols over how acces­si­ble a machine is. From here, one must estab­lish a level of trust to han­dle rela­tion­ships between machines. This should include some basic cat­e­go­riza­tion, user being the low­est level of cat­e­go­riza­tion, then rais­ing up to dif­fer­ent group­ings. For exam­ple, a user could be a mem­ber of a team, that team could be a sub­set of a larger divi­sion, which itself would be a sub­set of a com­pany, which would be a sub­set of an indus­try. The idea here is to auto­mate the process of iden­ti­fi­ca­tion and still ensure a degree of trust in order to main­tain secu­rity. While a piece of soft­ware can be net­work aware, the net­work may not nec­es­sar­ily want it to be aware of all resources. For exam­ple, if I am a vis­i­tor at BigCo, BigCo may not want me to have full con­trol over all their resources and full access to all their ser­vices. My machine should broad­cast my cre­den­tials and, based on that, have access to cer­tain resources.

Why Buddy Lists are NOT the way to go

Tim advo­cates the use of buddy lists to set up those rela­tion­ships. I would ven­ture to say that buddy list do not pro­vide the level of gran­u­lar­ity required. From there, there are two poten­tial ways to go: enhance buddy list to allow greater lev­els of cat­e­go­riza­tions or come up with a com­pletely new for­mat. I would be tempted to go for the for­mer as it is build­ing on top of an exist­ing standard.

Two way data and XML formatting

Tim makes a point that every piece of soft­ware should expose some ver­sion of its data as XML feeds. While I gen­er­ally agree that the data should be rep­re­sented in a com­mon for­mat, XML being the ideal choice, I object to it being a feed. What appli­ca­tions should pro­vide is an API that gives access to that data instead of a feed. The rea­son for the seman­tic dis­agree­ment I have here is that a feed is gen­er­ally pushed or pulled on a reg­u­lar sched­ule, no mat­ter whether it is needed or not. Pro­vid­ing an API would ensure that the data is only obtained upon request, there­fore con­serv­ing pre­cious net­work resources. A good exam­ple of feed mis­use was Point­cast, a soft­ware client that would poll the net­work every few hours for feeds. The prob­lem was that it would do so at the same time for every client on the net­work, thus gen­er­at­ing net­work traf­fic spikes on a reg­u­lar basis, and gen­er­at­ing much hatred from net­work administrators.

A proper API could be designed using either XML-RPC or SOAP as a way to carry its messages.

Where does the data go?

The other issue is where the data should reside. As a gen­eral rule, com­put­ers are no longer well suited as the only repos­i­tory of data. There is a need to rep­re­sent data in a fash­ion that makes it largely inde­pen­dent of the plat­form it’s run­ning on. A large part of the prob­lem here is who you trust (there’s that trust issue again) with your data. For exam­ple, buddy lists in AIM are stored on the  AOL servers. Do you trust them with that data? Would you trust them with more per­sonal data (writ­ten doc­u­ments, etc..) ? Would you trust Microsoft with it? Would you trust anyone?

This brings up inter­est­ing pos­si­bil­i­ties in terms of either keep­ing the data on a sin­gle com­put­ing device, from which it might be shared, or mov­ing it in a lot of dif­fer­ent places (mak­ing it more dif­fi­cult to ensure change con­trol and gen­eral data man­age­ment). This is an issue that still needs to be resolved.

Online/Offline

The one point that Tim does not cover is the online/offline chal­lenge. One can­not assume that a com­puter is always con­nected to the net­work. As much as we would like it to be that way, com­put­ers are often dis­con­nected from a net­work, whether it is on a plane ride, or when in a place where net­work resources are lim­ited or inex­is­tent. Pro­grams should be aware of that state and still be able to work prop­erly when offline. As a result, soft­ware should have a mode that allows it to check whether net­work resources are avail­able or not. If they are, it should check the shar­ing arrange­ments. If there are none, it should still pro­vide basic functionality.