.::output >> /dev/null::.

What if you made some changes to the data from one source? How would you resolve potential conflicts? Since you should be the only one accessing the information, you might be able to avoid this problem if you have an always-available repository. But what if you have devices like a Palm? Changes made to it are not reflected until you perform a sync. And if you were to modify the dates on the computer before synching with the palm, currently you can only accept changes from the computer or the palm (an exclusive or); there is no merge functions yet. Would subversion (or CVS) be the answer? But how would you get the masses to understand concepts such as commit, revert, merge, ignore (even I have problems resolving conflicts within CVS)?

If you think that is hard, what about trying to glue physical to digital? What if you write something with pen and paper (contrary to popular belief, the most ubiquitous form of recording information would still have to be the pen and paper)? How would you digitize that information? And if you have digitized it, then would you render your pen and paper version obsolete and throw it away? I do not think there is a way to resolve physical to digital conflicts. Ubiquitous computing can only happen between digital products.

Probably the most powerful computing equipment that you own would be you own PC. And it lies in your house. What level of computing power would you need when you are on the road? How much is too little, and what level would you define to be overkill? Why not just bring around a little device that can access your PC at home? Use some form of wireless connection to retrieve files that you need on the fly. If we do that, then how much information should the device be capable of displaying? Will it be able to support pictures, sound, movies? Who decides what it needs to support? And once someone determines what files it will support can you, as the user, ever change it according to the your needs? Must the user carry around his iPod to listen to music, his Palm for writing data, his notebook PC for programming tasks, his cellphone for communication?

Chris says: "There's an important lesson, in that monolithic solutions aren't that useful any more. Products need to be extensible and open at the edges to be useful". Again how extensible? More importantly, I believe since products will become more capable (but not necessarily better), the issues of migrating and upgrading should not be taken lightly. Migrating your files from an old machine to a new one can be more complicated than you think. What if you just found a better program? How are you going to migrate all your files in the old format over? Or how can you share existing files that have been written in non-standard schemes? Will we forever be limited to storing unicode text?

The main thing I am trying to emphasize here is that for me, there are so many more issues with ubiquitous computing. Would it be possible to implement some protocol that satisfies everyone? How many people do you have to be able to pleased before that product is marketable? I do not have the answers. We will have to see what this year holds for ubiquitous computing.

The glue might be becoming more of a reality. As The Tao of Mac puts it, SyncML is a realistic standard that should be adopted. This .pdf file does a fairly good job of providing an overview of what it is. In the end, standards are just standards and nothing prevents some company from inserting something into the XML schema that will break everything.

For some of the available toolkits please check out SyncML toolkits. For a more elaborate description of SyncML, these two links are very readable:

• XML Watch: Have data, will travel
• XML Watch: WMXML and basic SyncML requirements