[cap-talk] getting authorization from the user, GUI transactions/undo

John Carlson john.carlson3 at sbcglobal.net
Tue Oct 2 13:08:52 EDT 2007


So I'm thinking about how to get authorization from the user, and  
what ways to do it.  I am sure someone can send me a link for ways to  
do it.  Here's ways that I can see for the user to authorize the  
system to do an action:

1.  Copy and Paste
2.  Drag and Drop
3.  Select an icon, file or folder to open or save
4.  Typing
5.  Mouse click
6.  Basically, a lot of GUI stuff.

My question is, is every action the user makes authorization?  For  
example, does drawing a line give the system authorization to change  
an image?  Or does opening the image give the user the authorization  
to draw a line?   What draws the line between something that requires  
authorization and what doesn't?  Or is authorization something that  
is inherent in the design?

What authorization should entering a URL into a web browser give?

1.  The authorization to change the visual effect of the web browser  
window.
2.  The authorization to communicate over the network to any machine  
with standard protocols ( a protocol capability?  Can we grant HTTP,  
HTTPS and FTP, but not TCP or UDP?)
3.  The authorization for the page to receive user interface events.
4.  The ability to cache?

What authorizations should not be allowed?

1.  The ability to open any file on the system.
2.  The ability to communicate with non-standard protocols over the  
network?

Obviously you could say that saving the image is the correct place to  
put authorization, but my comment would be, what if we have multiple  
transactions (undos), and each change to the image actually changed  
the persistent object, and the user could just run through a bunch of  
rollbacks to get back to the original image (Undo All, Undo all in  
session).  Say the transactions were persistent too, so that the user  
could get right back to the correct transaction state if the system  
reboots.  We could give the user the option to clear the transactions  
if they were running out of disk space.  Should every application  
have transactions? What is the difference between a transaction and a  
contract?  Invoking a contract would cause the system to flush the  
transactions (they would move to auditing).  Are constructing  
transactions too onerous for the application developer?  To the web  
developer?  What if I am just
viewing readonly?  Should I have transactions for navigation?  What  
happens to the transactions if access to the image is revoked?






More information about the cap-talk mailing list