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

Actually i had considered something like this before castaway did her patches. I wanted to intorduce the concept of a deferred table. Basically every node on pm has a nodetype (which is itself a node). Nodetype nodes store the tables used to create a given node. So if the tablelist is 'node,document,user' when a node of that type is fetched or inserted it will insert a record into each of those tables (joining on ${table1}_id==${table2}_id). What i wanted to do was have a special marker (i was thinking '!') that would flag that the table is deferred. The table would NOT be fetched unless specifically requested, but it would be inserted/deleted or updated if the object was new or the required fields were present.

I still think this is probably a useful idea, but its low priority as its a pretty intrusive change. Also with the design that castaway took we can support multiple pads for a user.



---
demerphq


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

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.