[Twisted-Python] Generic hierarchy interface

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Its time has come. The need is pretty clear, partially for blog/news and a lot for Reality, and I'm sure for a lot of other things I'm not aware of. Basically, what seems to be needed is an interface that allows for a protocol-defined hierarchy to protocol-specific data, organised based on protocol-specific meta-data. For example, consider email. The protocol-specific hierarchy describes message threads (which you are all hopefully familiar with). The meta-data is a portion of the xheaders ("References" and "In-Reply-To" in particular), and the data is the message body. The email implementation for this hierarchy interface would then need to parse headers and xheaders to determine the relationship, and make the appropriate messages available this available at the appropriate places. The appropriate places. There seem to be three basic relationships that are of interest: parent, child, and sibling. Accessor methods for these should be straightforward enough, and implementions would need to provide the details for each protocol of extracting them from the meta-data available. The other type of access would be absolute and relative "path" access. For example, "news://a.server.name/a.group.name/a.message.id". A Reality example: "reality://server/Sol/Earth/Kansas/Smallville/Clark_Kent" In this case, each level of depth would only need to implement a standard accessor interface to allow whatever it may contain to be accessable. I'm a little out of my element, so I hope this has been at least somewhat coherent ;) Anyone have comments, or notice and horrible flaws, or just see a plain better way to go about it? Jp - -- "One World, one Web, one Program." - Microsoft(R) promotional ad "Ein Volk, ein Reich, ein Fuhrer." - Adolf Hitler - -- 4:20pm up 27 days, 17:02, 5 users, load average: 0.00, 0.00, 0.00 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Dk7kedcO2BJA+4YRAnL/AJ45iIwfmCQSU4DXCPXtXbRhBLFTfACfYLO6 9fhOCu7iEG8mbOeTrsOdJr4= =zSD+ -----END PGP SIGNATURE-----

From: Jp Calderone <exarkun@meson.dyndns.org> Subject: [Twisted-Python] Generic hierarchy interface Date: Mon, 17 Jun 2002 17:04:32 -0400 (EDT)
Its time has come.
I have to agree, given that I recently deduced the need for, then spent some time working on a similar concept. It's also extremely hard to work on.
The need is pretty clear, partially for blog/news and a lot for Reality, and I'm sure for a lot of other things I'm not aware of. Basically, what seems to be needed is an interface that allows for a protocol-defined hierarchy to protocol-specific data, organised based on protocol-specific meta-data.
... and aggregation within a protocol-independent hierarchy too, I would say.
For example, consider email. The protocol-specific hierarchy describes message threads (which you are all hopefully familiar with). The meta-data is a portion of the xheaders ("References" and "In-Reply-To" in particular), and the data is the message body.
Interesting example. I always felt the obvious collection interface to e-mail would be the server/domain/user/mailbox hierarchy; groups are organized differently (and there would probably be different interfaces for organization by thread and organization by sender, let's say)
A Reality example: "reality://server/Sol/Earth/Kansas/Smallville/Clark_Kent"
*snrk*
I'm a little out of my element, so I hope this has been at least somewhat coherent ;) Anyone have comments, or notice and horrible flaws, or just see a plain better way to go about it?
Well, this sort of design is right up my alley. I've implemented similar (though less general) systems on many occasions. One might even say that the essence of Twisted itself is to be an informal system of this type. For that reason, I'd really like to see a formal interface of what a "TwistedObject" would be. The problem with this particular, extremely general, application of an "abstract hierarchy interface" is that it's not quite as abstract as we'd like to think. There are many problems that arise -- for example, you list the relationship of "sibling", which most hierarchy interfaces do not support. Python itself is a hierarchy interface, after all. The __getitem__ and __getattr__ interfaces implement identical hierarchies. The key problems at this point, I think, are the notion of asynchronous access, and ensuring homogeneity. twisted.python.roots technically addresses one of those problems, and could easily be modified to support the other, but it seems horribly ugly to me for some reason that I don't quite understand. Do you have any other ideas regarding a generic hierarchy interface? -- | <`'> | Glyph Lefkowitz: Traveling Sorcerer | | < _/ > | Lead Developer, the Twisted project | | < ___/ > | http://www.twistedmatrix.com |

Jp Calderone wrote:
Its time has come. The need is pretty clear, partially for blog/news and a lot for Reality, and I'm sure for a lot of other things I'm not aware of. Basically, what seems to be needed is an interface that allows for a protocol-defined hierarchy to protocol-specific data, organised based on protocol-specific meta-data.
Have you looked at the work done on URNs? While this page is old, it contains some good pointers to work that had been done in that area: http://ana-annex.lcs.mit.edu/~edward/urn/single.html
The appropriate places. There seem to be three basic relationships that are of interest: parent, child, and sibling. Accessor methods for these should be straightforward enough, and implementions would need to provide the details for each protocol of extracting them from the meta-data available. The other type of access would be absolute and relative "path" access. For example, "news://a.server.name/a.group.name/a.message.id". A Reality example: "reality://server/Sol/Earth/Kansas/Smallville/Clark_Kent" In this case, each level of depth would only need to implement a standard accessor interface to allow whatever it may contain to be accessable.
One thing to think about there is the lifetime of a hierarchical identifier and the transient nature of some data (like spatial indexing). - Bruce

I just checked in DOMWidgets, a major part of my life for the last few weeks. (That and Twisted-Zope integration) It's very late and I need to go home, but for the terminally curious, here's an example. Put this rpy in a static web directory and for god's sake, use the latest CVS.
participants (4)
-
Bruce Mitchener
-
Donovan Preston
-
Glyph Lefkowitz
-
Jp Calderone