There has been some discussion on the list about adapting various
discussion Products to the PTK. Paul and I have actually come up with
some tentative plans and ideas on this. I'd like to open a discussion
based on these ideas.
I'd like to first describe how two discussion products I am familiar
with are implemented, then discuss how I am considering applying these
concepts to the PTK, some of the features and abilities such concepts
would enable, and raise some questions I have about how it should be
implemented.
Confera (and presumably Squishdot?) used object containment to
structure forums and threads of responses. That is to say, the Confera
object contains posts, the posts contain replies, and the replies contain
additional replies.
The ZDiscussions Product (which is in lamentable condition) had the
advantage of the ZCatalog. (The ZDiscussion object itself _is_ a
ZCatalog.) Discussion items (posts, replies, potentially files, URLs,
whatever) were all contained by the ZDiscussions object directly. There
was no containment tree. The discussion structure was tracked by having
each item remember what it was in response to. The catalog can quickly
and easily answer questions like, "What objects are responses to this
object?" or "What items have so-and-so submitted?" to build thread-based,
author-based, or even content-based views of a discussion.
This is a very flexible design. It allowed the creation of another
Product based on ZDiscussions called ZDConfera, which used the ZDiscussion
engine but which was (theoretically at least, I don't know if anyone
tried) a drop-in replacement for Confera. It offered the same API as
Confera, and objects looked like they contained one another, but in fact
they didn't.
Now, with PTK, we have a global catalog. We can treat that like the
ZDiscussion object. With the simple addition of an 'in_reply_to'
attribute on PortalContent, we suddenly have the ability to make any PTK
object a reply to any other object, regardless of where it physically
exists in the PTK site. This offers some really cool possibilities, but
also raises some difficult questions.
Let's say I'm viewing something I want to comment on. I click
'Reply'. What do I see? It could well be the entire list of Wizards,
meaning I could reply with any sort of object I like. I can see many uses
for replying with, say, a Link, with a description like, "This server does
many of the same things yours does, it may be worth investigating." In
most cases, though, it seems as though it would be best to use the
Document object, or an object specifically designed for discussions which
could do things like quote the replied-to item, munge the title with a
'Re:', whatever.
Where do these objects go? I would like to keep everything owned by a
Member somewhere within their personal space (which is their Member
folder). Whether it's in the folder directly or in some 'Discussions'
sub-folder, I'm not sure, but this highlights a general Zope problem.
Once users can start creating discussion items, they are much more likely
to produce a LOT of objects than they were before. It is quite difficult
for a user to manage a large number of objects in Zope. I am actually
inclined to hide a user's discussion items in the 'My Stuff' interface.
If that's the path we take, I would provide a 'My Discussions'
interface. This interface would not only allow users to manage their
replies, but it would allow them to see at a glance what discussions they
are engaged in, and which ones have generated new replies. I don't know
about anyone else, but I can't stand it when I have to manually hunt for
threads I'm involved in, and look for new items each time I visit a site.
What about non-member posting? I guess there should be a designated
location for anonymous items. Any thoughts?
Another problem-- suddenly, my objects are dependant on objects other
people own! What if I reply to something, then the owner of that
something deletes it? Actually, this is not terrible. My item is still
available via the catalog. It simply becomes the new root of it's own
sub-discussion. There may be some other issues here to consider. This is
sort of related to the registry/glossary issue.
An semi-relevant idea occurs to me just now which might provide the
answer to these issues. Perhaps only items which are not 'published'
('published' meaning having gone through Review and been made publicly
available) should be delete-able. Then you could use the portal policy
hooks to require Reviewer approval to 'un-publish' an item if that item
has dependants. Let's say I see something really cool on Joe's PTK site,
and I want to put a link to it on my own site. I could create a
lightweight, dependant object of a type designed for just this purpose,
and I would then be reasonably confident that my link will not one day
suddenly be pointing at nothingness without someone having given it
consideration.
Now that I've mentioned reviewing, I should maybe mention how
reviewing fits into my idea of replies. Essentially, this is another
portal policy decision. You can determine in policy that all objects of a
particular type (ie, Reply) get approved automatically, or at least have a
review request automatically generated. This should receive some more
consideration, tho. The average reply-submitter will be less savvy than
the average object-creator. They shouldn't have to care about things like
requesting a review in most cases. They shouldn't even have to know this
stuff goes on.
This is getting long, I'd better wrap up. Just to allay any concerns,
while this scheme (I don't plan, I scheme) allows you to implement a
portal where anything can have or be a reply to anything else, it does not
REQUIRE that that be the case on your particular portal. Decisions like
"Who can reply to this?", "What can they reply with?" etc, are made by
portal policy hooks. What other sorts of things do you need to be able to
determine in policy? What situations does this scheme not address? Can
you see any other areas which may cause difficulty that I have not brought
up? What sort of interface requirements are there? I am hoping to see a
most vigorous discussion-discussion (meta-discussion?) so that I know I'm
on the right track before I attempt to implement anything.
Thanks for reading this far! I really do appreciate it.
Mike.
--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434
discussion Products to the PTK. Paul and I have actually come up with
some tentative plans and ideas on this. I'd like to open a discussion
based on these ideas.
I'd like to first describe how two discussion products I am familiar
with are implemented, then discuss how I am considering applying these
concepts to the PTK, some of the features and abilities such concepts
would enable, and raise some questions I have about how it should be
implemented.
Confera (and presumably Squishdot?) used object containment to
structure forums and threads of responses. That is to say, the Confera
object contains posts, the posts contain replies, and the replies contain
additional replies.
The ZDiscussions Product (which is in lamentable condition) had the
advantage of the ZCatalog. (The ZDiscussion object itself _is_ a
ZCatalog.) Discussion items (posts, replies, potentially files, URLs,
whatever) were all contained by the ZDiscussions object directly. There
was no containment tree. The discussion structure was tracked by having
each item remember what it was in response to. The catalog can quickly
and easily answer questions like, "What objects are responses to this
object?" or "What items have so-and-so submitted?" to build thread-based,
author-based, or even content-based views of a discussion.
This is a very flexible design. It allowed the creation of another
Product based on ZDiscussions called ZDConfera, which used the ZDiscussion
engine but which was (theoretically at least, I don't know if anyone
tried) a drop-in replacement for Confera. It offered the same API as
Confera, and objects looked like they contained one another, but in fact
they didn't.
Now, with PTK, we have a global catalog. We can treat that like the
ZDiscussion object. With the simple addition of an 'in_reply_to'
attribute on PortalContent, we suddenly have the ability to make any PTK
object a reply to any other object, regardless of where it physically
exists in the PTK site. This offers some really cool possibilities, but
also raises some difficult questions.
Let's say I'm viewing something I want to comment on. I click
'Reply'. What do I see? It could well be the entire list of Wizards,
meaning I could reply with any sort of object I like. I can see many uses
for replying with, say, a Link, with a description like, "This server does
many of the same things yours does, it may be worth investigating." In
most cases, though, it seems as though it would be best to use the
Document object, or an object specifically designed for discussions which
could do things like quote the replied-to item, munge the title with a
'Re:', whatever.
Where do these objects go? I would like to keep everything owned by a
Member somewhere within their personal space (which is their Member
folder). Whether it's in the folder directly or in some 'Discussions'
sub-folder, I'm not sure, but this highlights a general Zope problem.
Once users can start creating discussion items, they are much more likely
to produce a LOT of objects than they were before. It is quite difficult
for a user to manage a large number of objects in Zope. I am actually
inclined to hide a user's discussion items in the 'My Stuff' interface.
If that's the path we take, I would provide a 'My Discussions'
interface. This interface would not only allow users to manage their
replies, but it would allow them to see at a glance what discussions they
are engaged in, and which ones have generated new replies. I don't know
about anyone else, but I can't stand it when I have to manually hunt for
threads I'm involved in, and look for new items each time I visit a site.
What about non-member posting? I guess there should be a designated
location for anonymous items. Any thoughts?
Another problem-- suddenly, my objects are dependant on objects other
people own! What if I reply to something, then the owner of that
something deletes it? Actually, this is not terrible. My item is still
available via the catalog. It simply becomes the new root of it's own
sub-discussion. There may be some other issues here to consider. This is
sort of related to the registry/glossary issue.
An semi-relevant idea occurs to me just now which might provide the
answer to these issues. Perhaps only items which are not 'published'
('published' meaning having gone through Review and been made publicly
available) should be delete-able. Then you could use the portal policy
hooks to require Reviewer approval to 'un-publish' an item if that item
has dependants. Let's say I see something really cool on Joe's PTK site,
and I want to put a link to it on my own site. I could create a
lightweight, dependant object of a type designed for just this purpose,
and I would then be reasonably confident that my link will not one day
suddenly be pointing at nothingness without someone having given it
consideration.
Now that I've mentioned reviewing, I should maybe mention how
reviewing fits into my idea of replies. Essentially, this is another
portal policy decision. You can determine in policy that all objects of a
particular type (ie, Reply) get approved automatically, or at least have a
review request automatically generated. This should receive some more
consideration, tho. The average reply-submitter will be less savvy than
the average object-creator. They shouldn't have to care about things like
requesting a review in most cases. They shouldn't even have to know this
stuff goes on.
This is getting long, I'd better wrap up. Just to allay any concerns,
while this scheme (I don't plan, I scheme) allows you to implement a
portal where anything can have or be a reply to anything else, it does not
REQUIRE that that be the case on your particular portal. Decisions like
"Who can reply to this?", "What can they reply with?" etc, are made by
portal policy hooks. What other sorts of things do you need to be able to
determine in policy? What situations does this scheme not address? Can
you see any other areas which may cause difficulty that I have not brought
up? What sort of interface requirements are there? I am hoping to see a
most vigorous discussion-discussion (meta-discussion?) so that I know I'm
on the right track before I attempt to implement anything.
Thanks for reading this far! I really do appreciate it.
Mike.
--
Mike Pelletier email: mike@digicool.com
Mild mannered software developer icq: 7127228
by day, super villain by night. phone: 519-884-2434