Hi! On Sun, May 17, 2009 at 00:44, Bernd Fondermann <[email protected]> wrote: > I think it's time to plan and discuss about internal representation of > items and all the other data held within the pusub module. Do some > bottom up OO engineering. How that will be taken up by the handlers will > later more or less fall into place.
Essentially we have to deal with three types of objects: - Node - User - Message We have two types of nodes, a) CollectionNode and b) LeafNode. Collection nodes are optional, so I will omit them for now. A LeafNode contains its configuration and meta-data. This would be the name, type etc. The LeafNode also knows its owners, publishers, banned users and members as well as the pending, unconfigured, and subscribed users. The Node is responsible for serializing itself to the appropriate stanzas (info, items, subscriptions etc). A LeafNode comes in various types (like PersistentNode, TransientNode etc. see XEP-0060 4.3, Table 4). A User can have several roles in a Node. So I'd introduce a User class for storing the user-information and a NodeUser class (dynamically linked to the User) for inclusion within the nodes. The NodeUser has Owner, Publisher, Outcast, and Member subclasses defining the permissions of the user in association with the Node. The Message class simply stores a message. Class-hierarchy: Node LeafNode PersistentNotificationNode TransientNotificationNode PersistentPayloadNode TransientPayloadNode CollectionNode User NodeUser Owner Publisher Member Outcast Message Dynamic model (classes in squared brackets are collection types): Node: Name:String ...MetaData... LeafNode: [Owner] [Publisher] [Member] [Outcast] Pending:[NodeUser] Unconfigured:[NodeUser] Subscribed:[NodeUser] [Message] ...MetaData... CollectionNode: [Node] User: JID:Entity or String NodeUser User Owner Publisher Member Outcast Message Content:String or XMLElement I hope the textual explanation makes sense. I think this is a useful model and will fit nicely in the current handler model. I'm a bit uncertain with the redundant storage of the user-states and roles. On one hand, we could throw each type in the pending, unconfigured, and subscribed collections and search through the lists to check if some user has the right to publish to the node (or change it...). Another alternative is to store everything in the owner, publisher, member, and outcast collections and search through it to collect pending and unconfigured users. I've chosen the middle ground with storing both informations in their respective collections which might benefit the performance when a large number of users are subscribed. To check whether a user is one of the owners of a node, all I have to do is go through the owners list. To send a message to all subscribed users, I'd go through the subscribed list and trigger the, say, sendMessage (or so) method. I think explaining the interactions between the objects takes up more time than to implement it, but essentially each object is responsible to create the stanzas the handler requests. Some details surely will change when implementing it, but roughly this is how I'd do it right now. WDYT? Cheers, Michael
