All this recent discussion of handles hasn't be sitting right with me and I think I understand why.
What is a handle? The most common form of handles that programmers are familiar with is file handles. A file handle is a kind of pointer that the file system maintains for you. Lots of things are going on during a typical file manipulation action that the application program really isn't interested in. e.g., the blocks that make up the file could be moved around physically on disk by the filesystem to optimize space (or whatever) and, as far as the application is concerned, the file is unaffected. The handle is an abstraction mechanism. It is well known that this is the power of a filesystem. Abstracting away the lower-level implementation and demanding that applications work with files allows the filesystem to be flexibly implemented to achieve the best performance or whatever other goals are desired. The majority of algorithms currently implemented in OpenCog have an intimate knowledge of the layout of Atoms in an AtomSpace. The use of handles is not at all similar to the filesystem concept. There's no abstraction going on. If the representation of an Atom was to change, we would expect the use of handles to be of little value in mediating the maintenance of these algorithms. I think Linas knows where I'm coming from here.. his use of for_each patterns is an attempt to encapsulate the layout of Atoms in an AtomSpace and abstract away the interface.. but I think we need more. Consider moving the Query algorithm out into a separate server. The primary operation of the Query algorithm is to walk the nodes and links of an AtomSpace and do isomorphic tree matching. One may be tempted to implement this by replicating the entire AtomSpace from the primary server to the Query server and keeping the two in sync. I believe this would be unnecessary as the Query algorithm is primarily a local one.. it is interested in walking trees from a given root. Instead, we could have an api which abstracts the Atoms in an AtomSpace, giving us handles, which can be used in operations to the server to walk the links between nodes, retrieve the data contained in nodes and perform complex searches. I suggest that such an API can be written to make communication with the Atom Server completely transparent.. just as communication via system calls to an operating system's kernel is completely transparent to glibc users. On the other hand, some algorithms belong in the Atom Server. For example, attention allocation. Although the exact strategy of attention allocation may not. Having such an abstract API to the AtomSpace will permit the easy binding of other programming languages. For example, the Relex code (written in Java) could be completely ignorant of the XML format used to communicate to the server. This will attract more contributors as everyone has their preferred language to develop in. It will also have pragmatic benefits as each language has its own strengths that we can leverage. Trent _______________________________________________ Mailing list: https://launchpad.net/~opencog-dev Post to : opencog-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/people/+me/+editemails More help : https://help.launchpad.net/ListHelp
