Michael Jakl wrote: > Hi! > > On Sun, May 17, 2009 at 00:44, Bernd Fondermann <bf_...@brainlounge.de> 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?
>From what I read in the spec so far this sounds good. Maybe I'd not model the user roles as subclassas but as an enum type, but this is already too implementation specific. What also needed are some higher level objects like a NodeRegistry and the like. I'll continue to read the spec and give feedback as you go. Bernd
