Great question! Yes we do understand the desire to support anonymous users. We have not yet put much thought into how this will be accomplished. However 2 ideas that immediately pop into my head are:
 
**A user would begin taking a anonymous survey. A random username/password would be generated and added to an anonymous group. We could then provide that random account username/password to the user so they can leave and return to the place they left off. This way every user who enters the anonymous survey would generate a new random username/password unless the provided a previously generated username/password.
 
That might not be the most scalable solution as you could be potentially generating thousands of random accounts, so another solution might be:
 
**If the survey is an anonymous survey a new progress is always generated for every user and is only good for the length of the browser session. This would prevent the user from leaving and returning to the same spot in the survey as there is no LS user tied to the progress but it would still allow use to track a response set.
 
Those are just 2 quick ideas which probably need more thought and I am sure there are other approaches. Since surveys that are anonymous will need to be marked as such that mark can then be used in some way to decide how progress is handled.
 
 
Michael


From: limesurvey-developers-bounces@lists.sourceforge.net [mailto:limesurvey-developers-bounces@lists.sourceforge.net] On Behalf Of Thibault Le Meur
Sent: Thursday, November 15, 2007 11:56 AM
To: limesurvey-developers@lists.sourceforge.net
Subject: Re: [limesurvey-developers] LimeSurvey 2.0 Prototype Architecture

Inline reply:

Macasek, Michael A. a écrit :
See below.... 

  
I suppose we will have to design the authorization system so that it 
will be possible to give permissions to read/write these questions
then.

***Yes the user model has to be built out quite a bit and it will
provide for this type of permissions.
  

=> Ok
Ok so page_sections are an extension view of our former question_groups

with more flexibility in their reuse/inclusion and their use in survey 
Pagination

**While it is potentially possible for survey sections to be reused in
other surveys the code does not allow for this at this time. It is
something we hope to include in the future.
  
=> Ok
  

Ok so this is the replacement of our old template system: it seems 
flexible.

Does "One cannot modify the layout components through the 
template_params" imply that layout components must be customized by 
modifying the "templates"object directly ?


***The layout components refer to parts of the question layout that do
not directly relate to one of the question_secions. For example in a
matrix question the table html tag is purely there for layout,
currently there is no way to use the template_params that are
associated with one of the question_sections to add a class to the
table html tag. Template_params are only capable of modifying the html
directly related to the question_section they are associated with (e.g.
you can add a class to an input html tag). While we understand why it
would be desirable to be able to add a class to the table html tag the
additionally complexity that would be added to the code/template_params
system is not something we wanted to get into at this point. For now it
is possible to overcome this by adding a class template_param to the
question object that will add the class the html tag that wraps the
question. You can then use CSS selectors such as
".classname_on_question_wrapper table" to style to table. Does that
help/answer your question?
  
Yes thanks this is cristal clear.



"However only one of those progresses can be marked as not completed.":

I would have said the opposite!
If I understand well, we record a user's answers on the fly in a 
progress object which memories the session status. The user may abort 
(willingly or not the session). He could get back later but as soon as 
he submits a full session (a progress object), he shouldn't be able to 
try again. thus I would have said "Only one progress can be marked as 
completed" !

*****There is only ever at most one active progress for a given user on
a given survey. The term Active Progress means that the user has not
yet completed taking the survey. It is possible for a user to have
taken and completed a survey previously, in this case there would be
completed progresses for that user on that survey. If an Active
Progress exists for a user on survey it is an indication that the user
has not yet completed taking the survey. If a user attempts to return
to a survey that has an Active Progress for that user on that survey
they will return to that survey at the point where they left off. Once
the user completes the survey it is marked as complete or inactive.
That Inactive Progress then hold all the information related to that
instance the user took the survey, this includes all the responses. If
a user attempts to take a survey where he/she has no Active Progresses
an new active progress is created and the user takes the survey.
  
Ok, I understand now that your goal is to be able to keep track of several responses-set for a given user: old ones are "Inactive Progress
" and the only one not-submitted is the "Active Progress" one. this is indeed interresting, for instance we could compare answers before/after.

But then: how do you handle anonymous surveys?
* Imagine you have a survey that requires neither an invitation code nor some kind of authentication
* an anonymous  participant begins to answer the survey but fails to proceed (no true submit) [could be because of a browser crash or because he decides to stop answering]
* a new (anonymous) participant tries to access the survey
=> Will the second one be presented partial answers from the first ?



interresting: will help reusing "tokens"

***I am not sure what you mean by "tokens" in this context.
  
I used the word 'tokens' with quotes to refer to our previous invitation code system in LS 1.x


  
The data model is missing:
* email_templates,
* languages,
* user/group roles,
* metadata and custom attributes, and
* versioning, just to name a few.

The difference between metadata and custom attributes is that:
* metadata is data that will de directly associated with an object (a
    

  
field) this consists of information that every LS admin will track 
such as full name of a user, email address of a user, etc.
* custom attributes will allow for LS admins to add additional 
metadata that is related to their particular domain to objects.
    
Best regards,
Thibault



  
Thanks for your answers,
Thibault