Well, the borg's scratchpad seems to be empty for the time being! :)

More seriously, could you please explain the benefits or implications of these changes? I have no clue.

The point was mostly to save moving around extra data needlessly. Previously, scratchpads were actually part of the USER object, so when grabbing the user data from the DB in order to do anything with it, up to 64k of scratchpad data needed to be grabbed as well, even if the purpose of getting the USER object wasnt to look at the scratchpad at all.

With the separation, this won't happen (at least when its pronounced stable enough to throw away the old scratchpad data), so there will be less needless passing around of unused data.

Also we may be able to do fun things like allow users to have multiple scratchpads, ones where they can set more specific view permissions, even share them (writeable) with others..

C.

I'm not familiar with the PM code, but in my work application I can mark a field 'defer', in which case normal fetches of the object won't fetch that field, and the accessor knows to do the extra fetch for deferred fields if the hash key doesn't exist. It looks something like this:

  if ($field->defer) {
    no strict 'refs';
    *{"${class}::$method"} = sub {
      use strict 'refs';
      my $self = shift;
      $self->load_deferred if !$self->{_blank} && !exists($self->{$met
+hod});
      return $self->{$method};
    };
  }
[download]

That is to say: we need to load deferred fields if this is a real object (!$self->{_blank}) and the field hasn't been loaded (!exists($self->{$method})).

I don't know how applicable this approach might be to PM, but it works fine for me. :)

Hugo

Cudos for the work you and others continue to put into the site.

For anyone who may think that passing around that extra data is nothing (well, unless you are connecting over dial-up), I can give you an example where it did make (or would have made) a difference.

Back in early December of this past year (2003), I spent a week out-of-town to apartment hunt prior to moving (at the end of that month). The hotel I stayed at had broadband access, and I had my laptop, so I thought, "no problem." On three consecutive nights, I got disconnected when I made a change to my scratchpad (I didn't make the association the first night, though). After several calls to the technical support group for the access, I found out that I had accidentally triggered (because of the combined size of my homenode and scratchpad at the time) their implementation of Snort, which was configured to watch for (among other things) attempts to exploit an overflow in CGIs by sending large chunks of data (Snort rule: WEB-ATTACKS /usr/bin/perl execution attempt, although I don't know if they had modified it or anything). While I wasn't affected by the issue after I found out the root cause (on the last evening before returning home), it did prove annoying, and could also prove to be an issue for other monks, in other situations.

If someone created "castaway's scratchpad" as say, a SoPW node, then I won't be able to view your scratchpad anymore.

Hear, hear. In what way is the SPV really obsolete? Can it not be brought up to date? I don't think a magic incantation to pull a scratchpad out of the search bar is the most elegant solution.

That said, I applaud the effort to remove the SPs for home nodes; it's something that's been talked about for a long time, and it's good to see it coming finally to pass.

In what way is the SPV really obsolete? Can it not be brought up to date? I don't think a magic incantation to pull a scratchpad out of the search bar is the most elegant solution.

No I'm very sure the SPV wont become obsolete. It may lag behind the main functionality until its settled down a bit but I'm sure it won't become obsolete. At some point somebody will end up synching it over. (I'm with you about linking btw.)



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Quite simple. Scratchpads have a nodetype of 'scratchpad', so simple send 'type=scratchpad' as a parameter to the script. To access my scratchpad for example, you'd use the following URL. This method will work 100% of the time (well, it should anyhow).

/index.pl?node=saskaqueer's%20scratchpad;type=scratchpad
[download]

http://perlmonks.org/index.pl?node_id=108949&user=sporty
[download]

Sportys Pad
And to edit:

http://perlmonks.org/index.pl?node_id=108949&user=sporty&svmode=edit
[download]

Edit Sportys Pad



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

I was hoping for a way that worked with the displaytype=xml. The new scratchpad nodes work with a displaytype=xml :\

Bart: God, Schmod. I want my monkey-man.

I'm confused, when I get the xml view of my home node, I still see the entire scratchpad and not only a reference to it. What went wrong? Would it be difficult to add to the xml view also a reference to the user's image?

The scratchpad column as you see it in the XML view of your homenode is not actually used anywhere now. If you update your new scratchpad, the scratchpad data in the 'users' database table is not updated. As for why the old scratchpad's contents still show up in the XML view, it's because that part just hasn't been changed yet. I'm pretty sure you'll see that disappear soon enough, since (from what I understand) the major reason for the switch to the new system was to get rid of this bulky scratchpad column in the database.

Doing some Super Search, gives now results beginning very often with perlmonk's scratchpad.

Nice new behaviour, but the filter selector allowing to exclude or restrict the search on them is present but disabled...

Do I have to configure something to enable it or is it a bug?

As always, you're awsome castaway. I hope that the idea was yours, as I want to give credit where credit is due. If not, brilliantly executed! Now if there is enough of the brown nosin' going on, I'll leave you alone to ponder your next stroke of genious (even though I can't spell!).