Re-2: persistent objects in runrev (howto)

[Richard Gaskin]

Franz wrote:

 > Coming from Toolbook I had to realize and accept that ...
 >
 > runrev password protection protects stacks against
 > * copiing objects FROM it
 > * editing passwords
 >
 > It does not protect the stack against
 > * copying objects INTO it (including scripts in this objects)
 > * deleting objects within it,
 > * moving around
 > * reading/writing custom properties of stacks or objects etc.
 >
 > This causes the behavior that you can copy an object (even a
 > background coming in front of the event hierarchy) INTO a
 > password protected stack - but you cannot copy a modified
 > object back then without putting the passkey ...

Yes, Rev's script protection does not attempt to hinder any form of 
alteration of the message path, it merely prevents scripts from being 
read.  If you could copy an object from a protected stack to an 
unprotected one, its scripts would become exposed.

There is a request to support password-protection of any object, not 
just stacks:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=659>

(Note to RunRev: I am not soliciting votes here, just noting an existing 
report that is relevant to the conversation.  Whether or not someone 
decides to add their votes for it is entirely at their own discretion. 
The readers here are not my zombie legion. <g>)


 > Because I have to copy the objects from my working stack to the
 > tempStack first I have to use stacks without runrev password
 > protection (to copy objects FROM) for my concept of persistent
 > objects.

If you're copying objects, you may find it both more secure and more 
convenient to maintain to have as few handlers as possible in those 
objects, which merely call handlers in a central library or your app's 
mainstack to do the real work, e.g:

-- In copied object:
on mouseDown
   DoSpecialMouseDownThang
end mouseDown

-- In some central location:
on DoSpecialMouseDownThang
   -- all the cool stuff your object does
   -- goes here
end DoSpecialMouseDownThang

Not only does this provide complete protection for your proprietary 
algorithms, but it also makes the code lighter in the copied objects, 
minimally reducing memory usage.  But more useful is that it keeps the 
complex stuff in one place, so it can be maintained and enhanced without 
needing to make sure that all copies of the script are kept in synch.


Just curious:  What options does Toolbook provide for script protection?

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com