With the recent changes to the scratchpad system, a question I'd been wanting to ask for quite a while popped back into my head: "Would it be possible to have two different scratchpads, one for public consumption and one for private use?". I know I can't be the only monk who wishes to be able to have a place to post things publicly and a separate 'sheet' to place things that are meant to be private. Currently, one could use their homenode as their 'public scratchpad', and then their scratchpad for their private use, but homenodes tend to contain a bunch of junk that doesn't really fit in with the scratchpad end of things.
I had feared asking this earlier because of the old implementation; surely this would have been more difficult and/or tedious to implement before now. Now that scratchpads are given their own node, it seems that permitting two scratchpads would be much easier to implement. Giving a separate node for the public/private scratchpads would most likely be extremely easy to do, though perhaps a combination of both on the same node would be better.
If the 'two scratchpads, one node' path were to be taken, it'd really only take an addition of another column to the nodetype table for scratchpads (priv_scratchpad or some such), and some (hopefully) minor changes to the code used to display the scratchpad nodetype. Anyone with access to the code is welcome to correct me on my 'this should be easy' attitude if it would not be as trivial as I think.
Is anyone else with me? Or am I alone with my desire for an additional scratchpad?
Sidenote: Super Search currently returns results to scratchpads that are private (demerphq, moen, 914, tos and zengargoyle may think their pads are private... but I know they all have 'foo' somewhere in the text!). Just pointing out an annoyance when searching; anyone who can do enough super searches to piece together what someone has on their private scratchpad deserves that reward :)
|
Re: Multiple scratchpads - one public, one private
by davido (Cardinal) on Jun 08, 2004 at 06:21 UTC
|
There has been a flurry of activity among pmdev to work out a few kinks that turned up with the implementation of the new scratchpad system. It's starting to settle down now, but probably not 100% put to bed.
In a recent node, Re: Re: New scratchpads, castaway mentioned the possibility of multiple scratchpads in the future, so your idea doesn't sound all that far-fetched to me at all.
What I think would be interesting would be group wikis (or group scratchpads). These already exist for the assorted PerlMonks cabal, but could be a useful tool for groups of PerlMonks working together on side projects. Such a thing might be helpful to a small group of developers working on one CPAN module together, for example. Maybe the Monastery isn't the place for that, and maybe it's too hard to administer effectively, but on the other hand, maybe it's a new area of support the Monastery could offer to Perl users. ...just a tangental thought. ;)
| [reply] |
|
|
| [reply] |
Re: Multiple scratchpads - one public, one private
by demerphq (Chancellor) on Jun 08, 2004 at 17:05 UTC
|
Multiple scratchpads with various permission models have been actively discussed amongst pmdev. And as davido said the patches most recently applied have moved us a long way towards having them. (Thanks castaway.)
OTOH, there has not been a policy discussion about it yet. My preference is to give an extra scratchpad to abbots as they currently have no other level powers. But my feelings on this arent particularly strong.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] |
|
|
I wouldn't suggest limiting such a feature to higher level members. That would be like saying you have to be level 6 until you can enable the chatterbox nodelet, and can't view the Newest Nodes page until you are level 8. Of course, I just typed that assuming you only meant an additional scratchpad per user.
Perhaps a different system has been devised? By 'various permission models', are you saying something more like a wiki system, to which a user can say who is allowed to access it and what permission bits (read, write, etc) each user is permitted? If so, perhaps limiting by level would be okay, but couldn't we just increase the number of such wikis a user can have, based on their level (such as votes are done). That way, a level 2 or 3 monk can still use the feature, but will have a small quota. By level 7, a user could be given the power to have more such wikis :)
| [reply] |
|
|
I wouldn't suggest limiting such a feature to higher level members.
Well, I dont know how clear cut that is. Each scratchpad can represent up to 64k of data. The less users have such a feature the better. Also IMO most folks that would actually take advantage of the feature would be abbot or above. Plus I dont think this feature is particularly essentially to the site and as such I dont feel bad about being a bit elitest about who can use it. But it should be recalled that im just the pmdev god. I have no role nor any intention of playin a role in setting site policy. So if you really hate this idea lobby the other gods that it shouldnt happen. And then it wont. But if it were up to me alone it would. :-)
By 'various permission models', are you saying
Well, im not saying anything in particular. Discussions have occured where the idea of being able to specify readers (not writers) was raised.
However you look at it dont hold your breath over this feature. If it comes itll come. But it isnt a priority for any of the active pmdev members that I know of.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply]
[d/l] |
Re: Multiple scratchpads - one public, one private
by Shinwa (Beadle) on Jun 08, 2004 at 21:47 UTC
|
| [reply] |
|
|
The problem with a public scratch pad is that it is public, and anyone can just come along and wipe it. If that's ok with you,
feel free to use Whats a wiki?. Less interesting is the publicly readable but writable only by gods Cloud nine.
<injoke>
Of course, we all know that if there were such a thing that were accessible only to, say, acolytes and above and writable only by abbots and above, it would be a productive place where much collaborative work could be done.
</injoke>
| [reply] |
|
|
I think we should change the wiki edit page to only allow janitors and owners (not writers) to be able to change wiki titles. We need to fix the canUpdateNode() and canReadNode() to special-case wikis so we can use them several places (and so regular displaytype=edit can work on wikis). Once that is done, I think we could do the following...
At ysth's suggestion, I could go for allowing members of a certain level to create a *single* wiki that they could change the title of and set the permissions on (you are limited to setting a minimum level or picking an existing group -- though if people start making requests for new groups to be added, I'm going to delete their wikis). The node=tye;type=user;displaytype=xml would report the node ID of my wiki if I had one like it will soon do for scratchpads. Super search would allow you to search wiki's by content, title, owner, just like it does for other nodes (we'll need to have it post-process the list and not list nodes that you don't have access to read, a simple change).
And, of course, gods can create wikis with a specific title and permissions if given a good reason to.
We'd want a superdoc that lists wikis sorted most-recently-updated first (create a bookmark that feeds it a specific list of wiki IDs if you only want to check for updates to certain wikis).
If your wiki gets wiped out (or otherwise ruined), then you can use "edit history" to see who changed it when and how and cut'n'paste removed parts back into existance (which should be a good reason for people to not bother wiping wikis). This "history" link needs to become public (in the "title chooser", where "print" and "xml" links are, preferably only if there are history records to see), not just in the janitors' nodelet. But we need to limit who can see the contents of edit records to not include those who can't see the node that was editted and to limit it somewhat for fully public nodes1.
You wouldn't be allowed to delete your wiki, but you could empty it and set the permissions so noone else can edit it. This is just so wiki node IDs don't scroll up and up when people can't decide whether they want a wiki or not.
The space required for wiki edit history could become rather huge, which is one reason why only one wiki per person and only after you reach a certain level. pmdev implementing "preview" for wikis could help a lot with that. A purge process will eventually be needed either way (and I believe in lots of history, so I wouldn't purge records less than 1 year old).
If your wiki becomes a great success, then it could be adopted by the gods (which would make its title and permissions somewhat set in stone) so that you could create a new personal wiki.
1 Some appear to not want the public to be able to see edit history of nodes (every edit to a wiki is recorded; for other node types, only edits done by janitors are recorded). I guess one point is to prevent robots from finding e-mail addresses that were removed when someone realized the spam risk. I'm not sure we should prevent the public from seeing edit history, but perhaps just restricting it the registered users would be enough? That prevents anonymous monks from seeing how a node change which they certainly may have valid reason to do, but I don't feel too sorry for them if they have to register for that access even if they feel that they never want to post via that account.
| [reply] |
|
|
