Hi Philip, Let me see if I can sort some things out from your message:
On Saturday, February 2, 2013 12:51:42 PM UTC-5, Philip Buckley wrote: > > As an end-user rather than a developer, I must admit I don’t really > understand the significance of “in core” versus “in a core plugin”. > There are three "conditions" code can be in: 1. Core Code -- Core code is any part of Habari that is not a plugin or theme that is packaged in the release. If you download Habari, most of it is "core". 2. A non-core plugin or theme -- A non-core plugin or theme (usually just "plugin" or "theme") is something you download from somewhere after you've installed Habari. It does not come with the main distribution package. 3. Core Plugin -- A core plugin or theme is a plugin or theme that comes with the core distribution package. These addons are slightly different than ones you get separately for three important reasons: a. Everyone gets core plugins whether they want them or not, because they're within the core download package. b. Core plugins are maintained along with Habari's core code itself. They're expected to be regularly maintained, and excised if they're not. c. If you install a vanilla Habari, the core plugins always appear in the list of plugins to activate in the installer, and some of them are even marked *by default* for activation. This is to remove as much configuration as possible from the process of installing a baseline useful Habari, while still allowing advanced users to remove those basic features either to replace them with something more advanced or omit them from their specialized installs. A core plugin example is the autop plugin, which converts double line-breaks in your post content into paragraphs in HTML automatically. I routinely disable this plugin in my installations to replace it with my custom plugin, selectivep, which lets me only apply autop to specific types of posts. > I find Owen’s comparison of Revisions with Taxonomy intriguing. Taxonomy, > as I understand it, is in the abstract about how you group things (in the > case of Habari those things are posts) and Revisions, one could say, in the > abstract are about how you deal with the history of something (in the case > of Habari a post) If the logic is that taxonomy (the abstract) is in core > and concrete things can be done with it in plugins, e.g. a menus plugin or > a categories plugin, then I can see the logic of Revisions in core that can > be used via plugins to do concrete things, e.g. build a wiki or an > editorial workflow. Is that the logic? > Yes, exactly! As another example of how this division of labor is quite common in Habari, take the autop vs selectivep example from above. Both plugins apply paragraph tags to post content. The selectivep applies it only to some posts, and the autop applies it to all posts. But the filter functionality that creates the paragraphs is itself part of core. It's very likely, as a result of revisions being added to core that a core plugin will emerge that provides basic access to the revision data that Habari is storing. Admins are welcome to disable that plugin and instead use something more robust. > One thing that has been mentioned in the course of the discussion is the > potential of building an editorial workflow on Habari with Revisions. This > is something I have thought about before, and I am very excited by the > potential. What I have thought about before is an editorial workflow in a > multi-user setup, and the one fundamental thing I would need is a way to > prevent 2 people editing the same post at the same time. If I understand > correctly how Owen has implemented revisions, the revisions made by 2 > people of a post would result in each of their revised versions being > stored, so one could always go back to one or other person’s version. > However, for what I have in mind I would really need a single post that was > edited by person A, then by person B (or vice versa, by person B, then by > person A), but not by the two simultaneously. Does anyone have any thoughts > how theoretically this could be implemented? And whether it would be a > difficult or easy thing to implement? > This is a complex problem. As Chris Meller points out, 0.9 can handle this situation, but it does so in a surprising and poor manner. If users A and B begin editing the same post, and user A saves their version before user B, user B is informed that the post was changed in the interim, but user B's version is lost. This is a problem. There are many ways to try to solve this problem, but what is the best thing to do? What should appear when user B tries to save? Should they see their version? User A's? Should it show a comparison of both versions to the original? What if user C also saves a version in the interim? Or should it lock user B out of editing until user A is done? But then what if user A abandons editing and leaves the post locked? At worst, storing revisions would prevent data loss. Data loss has always been a no-no for Habari, so this seems like a big win. Then, figuring out a way to make revisions useful for the kind of collisions you're talking about will be possible. I hope I've explained that all well. Maybe you can help describe what Habari or a plugin should do with all this? Owen -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev --- You received this message because you are subscribed to the Google Groups "habari-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
