Hiroki, In the earlier designs, before SDS was ever coded, group membership was queryable for any specific time. The SDS was to record the history of all group membership events (create, join, leave) and be able to answer both with that history and deduced snapshots of any point in time.
So along with "who is in the group now?" the portal could ask, "who was in the group yesterday at 9am?". I have no idea what the status of this design is at this point. -Turadg On May 24, 1:26 pm, Hiroki <[EMAIL PROTECTED]> wrote: > One more thing that I would like to throw in this discussion is "What > happens when students change workgroups? How are their saved-data > associated to them?" > > For example, consider this sequence of action: > A,B,C are students > 1) A&B work together in workgroup 1, C works in workgroup 2 > 2) A moves to workgroup 2, works with C; B works in workgroup 1 > 3) A moves back to workgroup 1, works with B; C works in workgroup 2. > > If I remember correctly from our discussion in last year's retreat, > all of the data gets stored, along with the workgroup membership? If > so, how can the portal access this information? For example, how can > the portal access all of the work that Student A did? > > Is there some kind of documentation for the above scenario? This > might be something we can discuss next Wednesday at the SAIL meeting? > > Hiroki > > On May 24, 9:58 am, laurel <[EMAIL PROTECTED]> wrote:> Just so you know what > I'm working on and why all the questions, I'm > > working on the portal code to update workgroups and by extension > > workgroup memberships. > > > I am finding that on the SDS now I can go to the web interface and > > remove all users from a workgroup. This does not cause any failures. > > > While the use cases are questionable, I'm just feeling uncomfortable > > with the change in the way things work for a boundary case. If I can > > update a workgroup to a brand new set of users, why doesn't updating > > with <workgroup-members></workgroup-members> remove all the users? > > > That just seems wierd to me. > > > Laurel > > > On May 24, 11:05 am, Aaron <[EMAIL PROTECTED]> wrote: > > > > Laurel- > > > > The xml for an empty workgroup should now be fixed. (And apparently > > > is... I love quick easy fixes.) > > > > Technical details: > > > The nil-class element was an artifact of the built-in ruby xml > > > generator. Basically it was being passed an empty array, and since > > > ruby isn't a typed language, it had no idea what type of objects the > > > array was supposed to hold, hence the nil-class. When there's at > > > least 1 object in the array, it can figure it out based on that > > > object's class type. I provided an override for the empty set, so > > > that it still puts the expected xml. > > > > As far as removing all the users from a workgroup, what's the use > > > case for this? I can see creating a temporarily empty workgroup, but > > > then once it has members, why would you need to go back to being empty? > > > > -- Aaron > > > > On May 24, 2007, at 10:57 AM, laurel wrote: > > > > > Wow...I wrote the test code for this and by the time I'd finished > > > > writing it, it worked...talk about quick response. Laurel > > > > > On May 24, 10:32 am, laurel <[EMAIL PROTECTED]> wrote: > > > >> Thanks Aaron - I should have remembered that. > > > > >> I have another question > > > > >> 1) I create a workgroup, but have not yet created members for that > > > >> workgroup. I can see this as a use case where a teacher decides to > > > >> create 4 workgroups for his/her class but leaves the assignments to > > > >> the students or just puts it off until later. > > > > >> 2) I do a query to find out the members of the workgroup (there are > > > >> none) and get the response below > > > > >> curl -i -X GET -H 'Accept: application/xml'http:// > > > >> rails.dev.concord.org/sds/4/workgroup/1403/membership > > > >> HTTP/1.1 200 OK > > > >> Date: Thu, 24 May 2007 14:25:23 GMT > > > >> Server: lighttpd/1.4.11 > > > >> Content-Type: application/xml > > > >> Cache-Control: no-cache > > > >> Content-Length: 68 > > > > >> <?xml version="1.0" encoding="UTF-8"?> > > > >> <nil-classes> > > > >> </nil-classes> > > > > >> I think it would be more useful to return the same response as a > > > >> workgroup with members, but with an empty set of members...That way > > > >> the same code could be used to parse the response. > > > > >> i.e. > > > > >> <workgroup-memberships> > > > >> </workgroup-memberships> > > > > >> Could that change be made? > > > > >> Thanks, > > > > >> Laurel > > > > >> On May 23, 3:47 pm, Aaron <[EMAIL PROTECTED]> wrote: > > > > >>> Hi Laurel- > > > > >>> It turns out that a change made to the dev sds a while back was that > > > >>> "users" are now "sail-users", and this apparently affects some of > > > >>> the > > > >>> REST API's. I will update this on the REST API confluence page (and > > > >>> determine if any other API's are affected). > > > > >>> So if you change the xml you're posting from: > > > >>> <user-id>5362</user-id> > > > >>> to: > > > >>> <sail-user-id>5362</sail-user-id> > > > > >>> it should work. > > > > >>> Full xml: > > > >>> <workgroup-memberships> > > > >>> <workgroup-membership> > > > >>> <sail-user-id>5362</sail-user-id> > > > >>> </workgroup-membership> > > > >>> </workgroup-memberships> > > > > >>> -- Aaron > > > > >>> -- > > > >>> Aaron Unger > > > >>> The Concord Consortium > > > > >>> On May 23, 2007, at 2:45 PM, laurel wrote: > > > > >>>> Hi all, > > > > >>>> I'm doing the following on the SDS (using curl) and having problems > > > >>>> and I'm wondering if anyone can help. Note that in step 2 I > > > >>>> don't seem > > > >>>> to get members in my workgroup, despite the fact that I've just > > > >>>> created one. Can someone related to the SDS check out my > > > >>>> technique and > > > >>>> possibly suggest what I am doing wrong. Thx. > > > > >>>> Laurel > > > > >>>> 1) creating a membership list for a workgroup > > > > >>>> curl -i -H 'Content-Type: application/xml' -X POST -d '<workgroup- > > > >>>> memberships><workgroup-membership><user-id>5362</user-id></ > > > >>>> workgroup- > > > >>>> membership></workgroup-memberships>'http://rails.dev.concord.org/ > > > >>>> sds/4/workgroup/1375/membership > > > > >>>> HTTP/1.1 201 Created > > > >>>> Date: Wed, 23 May 2007 18:22:01 GMT > > > >>>> Server: lighttpd/1.4.11 > > > >>>> Content-Type: application/xml > > > >>>> Location:http://rails.dev.concord.org/sds/4/workgroup/1375/ > > > >>>> membership > > > >>>> Cache-Control: no-cache > > > >>>> Content-Length: 0 > > > > >>>> 2) retrieving a membership list for a workgroup > > > > >>>> curl -i -X GET -H 'Accept: application/xml' > > > >>>>http://rails.dev.concord.org/sds/4/workgroup/1375/membership > > > > >>>> HTTP/1.1 200 OK > > > >>>> Date: Wed, 23 May 2007 18:22:08 GMT > > > >>>> Server: lighttpd/1.4.11 > > > >>>> Content-Type: application/xml > > > >>>> Cache-Control: no-cache > > > >>>> Content-Length: 184 > > > > >>>> <?xml version="1.0" encoding="UTF-8"?> > > > >>>> <workgroup-memberships> > > > >>>> <workgroup-membership> > > > >>>> <sail-user-id nil="true"></sail-user-id> > > > >>>> </workgroup-membership> > > > >>>> </workgroup-memberships> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
