|
Saturday, September 28, 2002 |
|
Didn't know that was a product... My son-- 2 years old-- has a fish tank with 4 gold fish and a random pond fish (a blue gill, to be specific). I was kind of worried about what to feed the blue gill during the winter-- it'll eat scrambled eggs begrudgingly, but really prefers insects and worms. Hard to dig worms when the ground is frozen. Thankfully, I found Fluker's 100% Freeze Dried CRICKETS today. Problem solved.
Ok-- strange product. However, the Can o' Crickets and Can o' Grasshoppers was a bit much. Key selling point: packed in their own juices!. |
|
Recently, Ronald Oussoren has effectively rewritten PyObjC. The PyObjC module is a python module that provides for transparent messaging from python into ObjC. That is, you can interact with Objective-C based objects from Python just like they were any other python object. Ronald added the ability to subclass Objective-C classes from within Python. From there, he added the support necessary to build full-fledged Cocoa applications using nothing but Python.
In the last few days, I worked out how to build a completely standard Cocoa Application Project Builder project that happens to be implemented in pure Python. The screenshot shown is the first real application that I have put together with this technology. Given the URL to an XML-RPC server, the application will query the standard introspection methods (see my previous posting) to display information about the server's API. The python source for the main window controller class is available via sourceforge. The code is not well factored -- in particular, I would first factor out all the generic toolbar stuff into an abstract class. By using Python to implement this application, I was able to significantly reduce the number of lines of code used to interact with the XML-RPC servers -- Python's implementation of xmlrpclib is quite a bit easier to interact with than the Core Foundation Web Services API (not a slight on the WS API, at all-- it is a great, highly functional and versatile, API). If you are interested in playing with this stuff, I would suggest installing python via Fink (or install the Framework build) and check out the subclass-branch of the pyobjc project.
UPDATE: All of the changes have been moved to the trunk -- you do not need to check out the branch!! |
|
About a week ago, I wrote a story that discusses the benefits of implementing the "standard" XML-RPC introspection methods. As encouragement, I tossed together a little python script that can be used to query an XML-RPC server for a list of all methods that implements, each method's signature, and any documentation that the server might provide on each method (using listMethods, methodSignature and methodHelp).
The python script source is available via a link found at the head of the article. |
|
Heh -- oops. I should have known those opaque SSL packets between .mac and iSync may be a proprietary protocol. Turns out that iSync is not using SyncML at this time. SyncML has been mentioned many times in the same context as iSync, but it ain't in there yet!
Regardless of protocol, the problems remain the same -- intelligently mapping fields between devices that have very different representations of the same kind of data. |
|
iSync is out. Wow! Very cool. Apple has wrapped a highly functional and easy to use interface around the SyncML protocol. We helped integrate SyncML into Ukibi's product exactly one year ago. The protocol is not without issues, but none that are fatal. We built the server side of the sync solution while one of their engineers worked on the Outlook and Palm clients. It worked really well. The key problem with SyncML and synchronization in general is one of figuring out how to map one device's fields to another devices. For example, Ukibi's backing store allows for any number of addresses, phone numbers and email addresses to be associated with any given contact. However, Outlook allows only three "entries" per contact -- a business, a personal, and an other entry. Each Outlook entry works in a subtly different fashion; has different fields, etc... The key challenge was to figure out how to map from one to the other such that information was never lost from a particular device and consecutive syncs would not cause a cascade of changes to bounce back and forth. It looks like Apple has put a lot of effort into resolving these kinds of issues, including support for SyncML's conflict resolution process. Note that if you have duplicate entries in two separate devices-- say in your palm and your phone, the first sync will very likely yield a duplication of information. There isn't anything that can be done about this -- SyncML's conflict resolution mechanism relies upon being able to uniquely identify each record on each device and, if necessary, map between them. It is a non-trivial problem and no solution will be 100% at first sync. Apple seems to have addressed the conflict resolution problem with a pretty good solution. The conflict resolver shows you the conflicting entries on the two devices and asks you to choose one (I did find a bug, though -- off to report that!).
In any case -- very very cool stuff! Apple continues to build awesome and compelling solutions on top of open standards. |
Last update: 1/5/04; 9:37:52 AM .
