This application needs to allow its primary user, who is a professional facilitator conducting a process interview with a client, to:
1. Log in securely (to the app and/or the Web location)
2. Create a new document on the server (transparently to the user, who is decidedly NOT technical)
3. Update the document on the server as he or she asks questions and receives responses (i.e., the document needs to replace or update itself on the net as the user requests that it do so)
4. Locate and retrieve documents from the server, limited only to those created by the particular user, and either view, print or revise those documents
One other user, the supervisor, needs to be able to access all documents regardless of which interviewer created them, and review, print, or revise them.
The only tricky part is that there are two stages in this interview process where the precise number of times the question has to be asked and answered is not known in advance.
I want to create a desktop app in Rev that will handle all the UI, data validation, and communication with the server. I have already designed the window and its screen contents as well as the interaction.
The issues I have relate to the interaction between the desktop app and the server from a Revolution perspective.
1. Security is a significant concern. The interview data contains highly personal information about the interviewee. I suspect I'll want to use SSL for the Web connection but it's not clear to me what if anything I need Rev to be able to do to handle SSL and whether there are any gotchas lurking there.
2. I particularly do not want to send login ID and password for the facilitator in the clear. What encryption issues will I encounter in Revolution? Are there encryption algorithms that already work in Rev or will I need either to hook into an Open Source solution or roll my own?
3. Does anyone see any major issues, problems, concerns, or flat-out roadblocks I should think about as I re-design this app?
4. One of my big issues is that if I design this as a document-centric app -- which it seems to want to be -- I won't be structuring the text much, except perhaps for display purposes. As opposed, e.g., to producing a mySQL app (which I could do but which seems like almost as much overkill as my current Zope solution), where the data would be stored presumably more efficiently. But since I *never* need to retrieve only part of the document, it seems most useful from a design perspective simply to treat it as a document.
OK, I'm shutting up now and listening for input.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Shafer, Revolutionary Author of forthcoming 3-book set, "Revolution: Programming at the Speed of Thought" http://www.revolutionpros.com for More Info
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
