|
|
|
Timo Stollenwerk
|
Hi,
as requested by Eric Steele, here is my PLIP: https://dev.plone.org/plone/ticket/9288 I'm one of the Plone GSoC students, and Martin Aspeli is my mentor. We set up a project tracker here: http://www.pivotaltracker.com/projects/15135 and we are planing to do a first release next week. Also, we set up a prototype for testing the UI: http://gsoc.timostollenwerk.net Cheers, Timo ### A proposal for an improved commenting infrastructure for Plone. == Contents == 1. Motivation 2. Proposal 3. Implementation 4. Deliverables 5. Risks 6. Progress Log 7. Participants == Motivation == The current Plone discussion framework is very basic and lacks functionality that is common in many Content Management Systems and blogs these days. Hence, third party developers feel the need to write their own commenting framework (e.g. qPloneComments and iqpp.plone.commenting). This leads to two major drawbacks. First, the comments are inconsistent within a single Plone site and second, the same administrative works as do be done twice. The motivation for this PLIP is to provide an easy to use and adjustable comment system using the existing services of Plone. Additionally to provide the possibility to re-use the commenting framework for third party products (e.g., if a developers feels the need for independent options for their product). In addition to the main goal, there are requirements for a state-of-the-art comment system. The Wordpress system may be used as an example and gives guidelines for a new system: * Moderation: It should be possible to enable moderation so that every comment has to be reviewed before publishing. * E-Mail notification: It should be possible to enable a confirmation email to be sent to the commenter to confirm the comment. * Captcha Support: Captchas or math questions should be supported and should be an option, e.g. "1+1 = 2" * Spam Protection: Akismet and other means of identifying spam should be supported. * Mass Editing Screens: Like in Wordpress, views for handling all comments of a subtree are useful to moderate comments or check their spam state. * Configurable Commenting Forms: It should be possible to decide which fields do actually show up in the form. * Extensibility: It should be possible for components to extend the comment form and the comment handling/workflow. An example is a plug-in which allows commenters to subscribe to further comments via email. == Proposal == As part of the Google Summer of Code 2009, Timo Stollenwerk (with Martin Aspeli as mentor) is developing a new commenting package. Martin set up the basic commenting infrastructure and made the basic design decisions for a zope3ish commenting framework (forms, views, adapters) which can be used by any content type. We propose to activate this new components for Plone's default content types by default. == Implementation == The plone.app.discussion package already has been created with the following [http://svn.plone.org/svn/plone/plone.app.discussion/trunk/plone/app/discussion/PRINCIPLES.txt architectural principles]: * Discussion items have a portal_type * Discussion items are cataloged * Discussion items are subject to workflow and permissions * Discussion items are light weight objects * Optimise for retrieval speed * Settings are stored in plone.registry * Forms are constructed using extensible z3c.form forms * Discussion items are stored in a BTree container * Discussion items are accessed using a dict-like interface * Discussion items are retrieved in reverse creation date order * Discussion items do not need readable ids * Discussion items send events == Deliverables == The basic commenting infrastructure is already in place. On August 24th, when Google Summer of Code ends, the plone.app.discussion package will be in a state that it can replace the current Plone commenting system. This doesn't necessarily mean that the system will be feature complete, but that the package will provide the basic features for a state-of-the-art commenting system This means, it is well tested and well documented, and migration of existing comments is possible. == Risks == * Already existing comments have to be migrated without restrictions. * There might arise conflicts with other, already installed commenting packages. Thus we have to look at these and make them work. == Progress log == We set up a story-based project planning tool, to manage the project and to track the progress: http://www.pivotaltracker.com/projects/15135 * GSoC started (2009-04-23) * Basic commenting infrastructure is in place (2009-05-13) == Participants == * Timo Stollenwerk * Martin Aspeli * Jon Stahl ??? * David Glick ??? * Lennart Regebro ??? ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
AnthonyG
|
Looks good. One useful (in my opinion) requirement that seems to be missing is to do with search: If you do a search and it matches a comment then the page that the comment relates to should appear in the search results.
Anthony _______________________________________ Anthony Gerrard SOS Children http://www.sponsorachild.org.uk/ Timo Stollenwerk wrote: > Hi, > > as requested by Eric Steele, here is my PLIP: > > https://dev.plone.org/plone/ticket/9288 > > I'm one of the Plone GSoC students, and Martin Aspeli is my mentor. > > We set up a project tracker here: > > http://www.pivotaltracker.com/projects/15135 > > and we are planing to do a first release next week. > > Also, we set up a prototype for testing the UI: > > http://gsoc.timostollenwerk.net > > Cheers, > Timo > > ### > > A proposal for an improved commenting infrastructure for Plone. > > == Contents == > > 1. Motivation > 2. Proposal > 3. Implementation > 4. Deliverables > 5. Risks > 6. Progress Log > 7. Participants > > == Motivation == > > The current Plone discussion framework is very basic and lacks > functionality that is common in many Content Management Systems and > blogs these days. Hence, third party developers feel the need to write > their own commenting framework (e.g. qPloneComments and > iqpp.plone.commenting). This leads to two major drawbacks. First, the > comments are inconsistent within a single Plone site and second, the > same administrative works as do be done twice. > > The motivation for this PLIP is to provide an easy to use and adjustable > comment system using the existing services of Plone. Additionally to > provide the possibility to re-use the commenting framework for third > party products (e.g., if a developers feels the need for independent > options for their product). > > In addition to the main goal, there are requirements for a > state-of-the-art comment system. The Wordpress system may be used as an > example and gives guidelines for a new system: > > * Moderation: It should be possible to enable moderation so that > every comment has to be reviewed before publishing. > * E-Mail notification: It should be possible to enable a > confirmation email to be sent to the commenter to confirm the comment. > * Captcha Support: Captchas or math questions should be supported > and should be an option, e.g. "1+1 = 2" > * Spam Protection: Akismet and other means of identifying spam > should be supported. > * Mass Editing Screens: Like in Wordpress, views for handling all > comments of a subtree are useful to moderate comments or check their > spam state. > * Configurable Commenting Forms: It should be possible to decide > which fields do actually show up in the form. > * Extensibility: It should be possible for components to extend the > comment form and the comment handling/workflow. An example is a plug-in > which allows commenters to subscribe to further comments via email. > > > == Proposal == > > As part of the Google Summer of Code 2009, Timo Stollenwerk (with Martin > Aspeli as mentor) is developing a new commenting package. Martin set up > the basic commenting infrastructure and made the basic design decisions > for a zope3ish commenting framework (forms, views, adapters) which can > be used by any content type. We propose to activate this new components > for Plone's default content types by default. > > == Implementation == > > The plone.app.discussion package already has been created with the > following > [http://svn.plone.org/svn/plone/plone.app.discussion/trunk/plone/app/discussion/PRINCIPLES.txt > architectural principles]: > > * Discussion items have a portal_type > * Discussion items are cataloged > * Discussion items are subject to workflow and permissions > * Discussion items are light weight objects > * Optimise for retrieval speed > * Settings are stored in plone.registry > * Forms are constructed using extensible z3c.form forms > * Discussion items are stored in a BTree container > * Discussion items are accessed using a dict-like interface > * Discussion items are retrieved in reverse creation date order > * Discussion items do not need readable ids > * Discussion items send events > > == Deliverables == > > The basic commenting infrastructure is already in place. On August 24th, > when Google Summer of Code ends, the plone.app.discussion package will > be in a state that it can replace the current Plone commenting system. > This doesn't necessarily mean that the system will be feature complete, > but that the package will provide the basic features for a > state-of-the-art commenting system This means, it is well tested and > well documented, and migration of existing comments is possible. > > > == Risks == > > > * Already existing comments have to be migrated without restrictions. > * There might arise conflicts with other, already installed > commenting packages. Thus we have to look at these and make them work. > > > == Progress log == > > We set up a story-based project planning tool, to manage the project and > to track the progress: http://www.pivotaltracker.com/projects/15135 > > * GSoC started (2009-04-23) > * Basic commenting infrastructure is in place (2009-05-13) > > > == Participants == > > * Timo Stollenwerk > * Martin Aspeli > * Jon Stahl ??? > * David Glick ??? > * Lennart Regebro ??? > > > ------------------------------------------------------------------------------ > _______________________________________________ > Plone-developers mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/plone-developers > ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli
|
Anthony Gerrard wrote:
> Looks good. One useful (in my opinion) requirement that seems to be > missing is to do with search: If you do a search and it matches a > comment then the page that the comment relates to should appear in > the search results. The page, or the comment? The current approach is that the comment appears in the search results, but when you view it, you see the page at an anchor where the comment is. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Hanno Schlichting-4
|
In reply to this post
by Timo Stollenwerk
On Wed, Jun 24, 2009 at 4:21 PM, Timo Stollenwerk<[hidden email]> wrote:
> https://dev.plone.org/plone/ticket/9288 > > == Proposal == [...] > We propose to activate this new components for Plone's default content types by default. I strongly disagree on this one point. Commenting should be an optional feature that needs to be explicitly enabled if desired. If a site wants to offer public feedback channels like comments or not should be a conscious decision. You need to have some form of process and responsibility defined for handling comments. What happens if there's an offending or inappropriate comment, what happens if there is spam (either because of missing spam protection or an ineffective one). Do you want to allow anonymous comments or do you want to require some form of authentication? There's no sensible defaults here which work across the very different set of sites build with Plone. Comments are in my opinion a perfect example of "opt-in" functionality. Hanno ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Jon Stahl
|
Hanno Schlichting wrote:
> On Wed, Jun 24, 2009 at 4:21 PM, Timo Stollenwerk<[hidden email]> wrote: > >> https://dev.plone.org/plone/ticket/9288 >> >> == Proposal == >> > > [...] > > >> We propose to activate this new components for Plone's default content types by default. >> > > I strongly disagree on this one point. Commenting should be an > optional feature that needs to be explicitly enabled if desired. > > If a site wants to offer public feedback channels like comments or not > should be a conscious decision. You need to have some form of process > and responsibility defined for handling comments. What happens if > there's an offending or inappropriate comment, what happens if there > is spam (either because of missing spam protection or an ineffective > one). Do you want to allow anonymous comments or do you want to > require some form of authentication? There's no sensible defaults here > which work across the very different set of sites build with Plone. > > Comments are in my opinion a perfect example of "opt-in" functionality. > > comments for Plone's core content types by default, and this behavior should not change. Custom content types (such as a "Blog Entry") can always choose enabled-by-default. :jon ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers -----
Jon Stahl, Director of Web Solutions ONE/Northwest - Online Networking for the Environment http://www.onenw.org |
||||||||||||||||
|
Michael Hierweck
|
In reply to this post
by Hanno Schlichting-4
Hi,
Hanno Schlichting wrote: > On Wed, Jun 24, 2009 at 4:21 PM, Timo Stollenwerk<[hidden email]> wrote: >> https://dev.plone.org/plone/ticket/9288 >> >> == Proposal == > > [...] > >> We propose to activate this new components for Plone's default content types by default. > > I strongly disagree on this one point. Commenting should be an > optional feature that needs to be explicitly enabled if desired. > > If a site wants to offer public feedback channels like comments or not > should be a conscious decision. You need to have some form of process > and responsibility defined for handling comments. What happens if > there's an offending or inappropriate comment, what happens if there > is spam (either because of missing spam protection or an ineffective > one). Do you want to allow anonymous comments or do you want to > require some form of authentication? There's no sensible defaults here > which work across the very different set of sites build with Plone. > > Comments are in my opinion a perfect example of "opt-in" functionality. To my mind we need a (per portal type) policy: [ ] Commenting always off [ ] Commenting always on [ ] Commenting configurable per instance, default off [ ] Commenting configurable per instance, default on Michael ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Timo Stollenwerk
|
In reply to this post
by Jon Stahl
Jon Stahl schrieb:
> Hanno Schlichting wrote: >> Comments are in my opinion a perfect example of "opt-in" functionality. >> > Actually, I agree with Hanno here. We currently do not activate > comments for Plone's core content types by default, and this behavior > should not change. Custom content types (such as a "Blog Entry") can > always choose enabled-by-default. I've just removed the sentence, right now commenting is deactivated by default in p.a.d anyway. Timo ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
AnthonyG
|
In reply to this post
by Martin Aspeli
I guess what's best would depend on an individual user's mental model of the site. Some users on some sites would see comments as being part of the page, in other cases they might be seen as separate entities attached to a page. The problem with the existing approach is that you might have many search results that all point to the same page. My feeling is that instead of this the comment should not be shown but instead boost the relevancy of the page in the search pushing it higher up the search results page.
I don't see this as a major issue either way - mimicking the existing behaviour seems OK also. Anthony Martin Aspeli wrote: > Anthony Gerrard wrote: >> Looks good. One useful (in my opinion) requirement that seems to be >> missing is to do with search: If you do a search and it matches a >> comment then the page that the comment relates to should appear in >> the search results. > > The page, or the comment? > > The current approach is that the comment appears in the search results, > but when you view it, you see the page at an anchor where the comment is. > > Martin > ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Alec Mitchell
|
In reply to this post
by Michael Hierweck
On Wed, Jun 24, 2009 at 8:12 AM, Michael
Hierweck<[hidden email]> wrote: > Hi, > > Hanno Schlichting wrote: >> On Wed, Jun 24, 2009 at 4:21 PM, Timo Stollenwerk<[hidden email]> wrote: >>> https://dev.plone.org/plone/ticket/9288 >>> >>> == Proposal == >> >> [...] >> >>> We propose to activate this new components for Plone's default content types by default. >> >> I strongly disagree on this one point. Commenting should be an >> optional feature that needs to be explicitly enabled if desired. >> >> If a site wants to offer public feedback channels like comments or not >> should be a conscious decision. You need to have some form of process >> and responsibility defined for handling comments. What happens if >> there's an offending or inappropriate comment, what happens if there >> is spam (either because of missing spam protection or an ineffective >> one). Do you want to allow anonymous comments or do you want to >> require some form of authentication? There's no sensible defaults here >> which work across the very different set of sites build with Plone. >> >> Comments are in my opinion a perfect example of "opt-in" functionality. > > To my mind we need a (per portal type) policy: > > [ ] Commenting always off > [ ] Commenting always on > [ ] Commenting configurable per instance, default off > [ ] Commenting configurable per instance, default on I'd say the current mechanism for comment enabling is close to perfect. We currently allow comments to be enabled/disabled per type globally, which makes sense since some types are not likely to ever need comments enabled, and others will almost always want comments in certain site configurations. Individual instances then default to the type-wide settings but can have comments enabled/disabled explicitly. I'm not sure there's anything I'd want to change about that. My one concern with commenting is that it's another large chunk of code to maintain which is not necessarily core-CMS functionality (though it is useful for a large number of sites). I have a feeling we may be better off jettisoning it entirely and relying on 3rd-party add-ons that integrate people's preferred discussion engines (e.g. IntenseDebate, Disqus, perhaps Google Wave, ...). I'd certainly like to see what this project produces before making any such judgement. In any case, I think it's important that whatever we end up with is easy to replace with some alternative commenting services/applications (i.e. the basic site/instance commenting configuration needs to be flexible enough to work with other implementations). Alec ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Dylan Jay
|
In reply to this post
by AnthonyG
On 25/06/2009, at 12:41 AM, Anthony Gerrard wrote: > Looks good. One useful (in my opinion) requirement that seems to be > missing is to do with search: If you do a search and it matches a > comment then the page that the comment relates to should appear in > the search results. +1 I've hacked the old comments to allow this behaviour. It should at least be an global option as to if search returns the object or the comment. > > Anthony > _______________________________________ > > Anthony Gerrard > SOS Children > http://www.sponsorachild.org.uk/ > > > Timo Stollenwerk wrote: >> Hi, >> >> as requested by Eric Steele, here is my PLIP: >> >> https://dev.plone.org/plone/ticket/9288 >> >> I'm one of the Plone GSoC students, and Martin Aspeli is my mentor. >> >> We set up a project tracker here: >> >> http://www.pivotaltracker.com/projects/15135 >> >> and we are planing to do a first release next week. >> >> Also, we set up a prototype for testing the UI: >> >> http://gsoc.timostollenwerk.net >> >> Cheers, >> Timo >> >> ### >> >> A proposal for an improved commenting infrastructure for Plone. >> >> == Contents == >> >> 1. Motivation >> 2. Proposal >> 3. Implementation >> 4. Deliverables >> 5. Risks >> 6. Progress Log >> 7. Participants >> >> == Motivation == >> >> The current Plone discussion framework is very basic and lacks >> functionality that is common in many Content Management Systems and >> blogs these days. Hence, third party developers feel the need to >> write >> their own commenting framework (e.g. qPloneComments and >> iqpp.plone.commenting). This leads to two major drawbacks. First, the >> comments are inconsistent within a single Plone site and second, the >> same administrative works as do be done twice. >> >> The motivation for this PLIP is to provide an easy to use and >> adjustable >> comment system using the existing services of Plone. Additionally to >> provide the possibility to re-use the commenting framework for third >> party products (e.g., if a developers feels the need for independent >> options for their product). >> >> In addition to the main goal, there are requirements for a >> state-of-the-art comment system. The Wordpress system may be used >> as an >> example and gives guidelines for a new system: >> >> * Moderation: It should be possible to enable moderation so that >> every comment has to be reviewed before publishing. >> * E-Mail notification: It should be possible to enable a >> confirmation email to be sent to the commenter to confirm the >> comment. >> * Captcha Support: Captchas or math questions should be supported >> and should be an option, e.g. "1+1 = 2" >> * Spam Protection: Akismet and other means of identifying spam >> should be supported. >> * Mass Editing Screens: Like in Wordpress, views for handling all >> comments of a subtree are useful to moderate comments or check their >> spam state. >> * Configurable Commenting Forms: It should be possible to decide >> which fields do actually show up in the form. >> * Extensibility: It should be possible for components to extend >> the >> comment form and the comment handling/workflow. An example is a >> plug-in >> which allows commenters to subscribe to further comments via email. >> >> >> == Proposal == >> >> As part of the Google Summer of Code 2009, Timo Stollenwerk (with >> Martin >> Aspeli as mentor) is developing a new commenting package. Martin >> set up >> the basic commenting infrastructure and made the basic design >> decisions >> for a zope3ish commenting framework (forms, views, adapters) which >> can >> be used by any content type. We propose to activate this new >> components >> for Plone's default content types by default. >> >> == Implementation == >> >> The plone.app.discussion package already has been created with the >> following >> [http://svn.plone.org/svn/plone/plone.app.discussion/trunk/plone/app/discussion/PRINCIPLES.txt >> architectural principles]: >> >> * Discussion items have a portal_type >> * Discussion items are cataloged >> * Discussion items are subject to workflow and permissions >> * Discussion items are light weight objects >> * Optimise for retrieval speed >> * Settings are stored in plone.registry >> * Forms are constructed using extensible z3c.form forms >> * Discussion items are stored in a BTree container >> * Discussion items are accessed using a dict-like interface >> * Discussion items are retrieved in reverse creation date order >> * Discussion items do not need readable ids >> * Discussion items send events >> >> == Deliverables == >> >> The basic commenting infrastructure is already in place. On August >> 24th, >> when Google Summer of Code ends, the plone.app.discussion package >> will >> be in a state that it can replace the current Plone commenting >> system. >> This doesn't necessarily mean that the system will be feature >> complete, >> but that the package will provide the basic features for a >> state-of-the-art commenting system This means, it is well tested and >> well documented, and migration of existing comments is possible. >> >> >> == Risks == >> >> >> * Already existing comments have to be migrated without >> restrictions. >> * There might arise conflicts with other, already installed >> commenting packages. Thus we have to look at these and make them >> work. >> >> >> == Progress log == >> >> We set up a story-based project planning tool, to manage the >> project and >> to track the progress: http://www.pivotaltracker.com/projects/15135 >> >> * GSoC started (2009-04-23) >> * Basic commenting infrastructure is in place (2009-05-13) >> >> >> == Participants == >> >> * Timo Stollenwerk >> * Martin Aspeli >> * Jon Stahl ??? >> * David Glick ??? >> * Lennart Regebro ??? >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Plone-developers mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/plone-developers >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Plone-developers mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/plone-developers ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Martin Aspeli
|
In reply to this post
by Alec Mitchell
Alec Mitchell wrote:
> I'd say the current mechanism for comment enabling is close to > perfect. We currently allow comments to be enabled/disabled per type > globally, which makes sense since some types are not likely to ever > need comments enabled, and others will almost always want comments in > certain site configurations. Individual instances then default to the > type-wide settings but can have comments enabled/disabled explicitly. > I'm not sure there's anything I'd want to change about that. Which is why we're not changing any of it. ;) > My one concern with commenting is that it's another large chunk of > code to maintain which is not necessarily core-CMS functionality > (though it is useful for a large number of sites). I have a feeling > we may be better off jettisoning it entirely and relying on 3rd-party > add-ons that integrate people's preferred discussion engines (e.g. > IntenseDebate, Disqus, perhaps Google Wave, ...). I think it's pretty much expected in a CMS like Plone that we have something like this out of the box. It's also something CMF and Plone have had since day dot. Taking it out would be the wrong way to go, IMHO. External web services may make sense for some sites, but not for most, I'd reckon. > I'd certainly like to see what this project produces before making any > such judgement. In any case, I think it's important that whatever we > end up with is easy to replace with some alternative commenting > services/applications (i.e. the basic site/instance commenting > configuration needs to be flexible enough to work with other > implementations). Right. Although we're not delivering it here, the design assumes that you should be able to at least store comments in an RDBMS, and probably also in an external web service, whilst being able to retain the admin GUI, the commenting GUI and possibly moderation (this has a catalog dependency, though). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
|
Alec Mitchell
|
On Wed, Jun 24, 2009 at 5:46 PM, Martin Aspeli<[hidden email]> wrote:
> Alec Mitchell wrote: > >> I'd say the current mechanism for comment enabling is close to >> perfect. We currently allow comments to be enabled/disabled per type >> globally, which makes sense since some types are not likely to ever >> need comments enabled, and others will almost always want comments in >> certain site configurations. Individual instances then default to the >> type-wide settings but can have comments enabled/disabled explicitly. >> I'm not sure there's anything I'd want to change about that. > > Which is why we're not changing any of it. ;) Great! >> My one concern with commenting is that it's another large chunk of >> code to maintain which is not necessarily core-CMS functionality >> (though it is useful for a large number of sites). I have a feeling >> we may be better off jettisoning it entirely and relying on 3rd-party >> add-ons that integrate people's preferred discussion engines (e.g. >> IntenseDebate, Disqus, perhaps Google Wave, ...). > > I think it's pretty much expected in a CMS like Plone that we have > something like this out of the box. It's also something CMF and Plone > have had since day dot. Taking it out would be the wrong way to go, > IMHO. External web services may make sense for some sites, but not for > most, I'd reckon. I'd say no matter how much work we put into Plone's commenting engine, it will never be a strong suit and is unlikely to adequately compete with most dedicated commenting engines (if only because our write performance is somewhat abysmal). Also, not all web-services are external. I do agree that now is not the time to be removing what has become core functionality, but I'm not sure it's the time to be rebuilding the whole thing from scratch either. Ripping it out for 5.0 and requiring an add-on would not be so radical (at least when compared to the other changes planned for 5.0). However, we would need a well-maintained quality add-on that provided stand-alone commenting to consider this option. I do think service based commenting engines (web services, WSGI middleware, etc.) are likely to become dominant in the near future. Anyone with a heterogenous portal is likely to prefer them, and anyone with a well-trafficked public site that allows comments is likely to as well. Such services provide convenience for users, require little maintenance and are likely to provide greater functionality and ease of administration than we are capable of. >> I'd certainly like to see what this project produces before making any >> such judgement. In any case, I think it's important that whatever we >> end up with is easy to replace with some alternative commenting >> services/applications (i.e. the basic site/instance commenting >> configuration needs to be flexible enough to work with other >> implementations). > > Right. Although we're not delivering it here, the design assumes that > you should be able to at least store comments in an RDBMS, and probably > also in an external web service, whilst being able to retain the admin > GUI, the commenting GUI and possibly moderation (this has a catalog > dependency, though). This would be great, though I think the RDBMS functionality is not quite as important web-service integration, it's likely to be much easier to implement. More important than that, I think, is that the entire commenting system be optional (though probably enabled by default), and that it remain easy to use the per-type and per-instance commenting configuration to manage alternative engines when the built-in engine is disabled. We should build this with the understanding that it will not be adequate for everyone. I'd be pleased with a pretty bare-bones default system if it was fairly trivial to create an alternative that relied on external services to do all the real work. BTW, can we move this discussion to the PLIP? Having two discussions for each PLIP is going to become a headache very quickly. Alec ------------------------------------------------------------------------------ _______________________________________________ Plone-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-developers |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |