[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