Hi Nate, I too have been waiting anxiously for responses to your original email on this, in hopes of understanding this area better. Did someone address your question verbally, and if so, could you please give us a summary of the response. If not, can someone please try to address Nate's questions?
Laurel On Feb 23, 8:11 am, "nate" <[EMAIL PROTECTED]> wrote: > Anyone have any pointers to wiki pages on this? What is the current > status of pod versioning? > > On Feb 14, 1:50 pm, Nathaniel Titterton <[EMAIL PROTECTED]> wrote: > > > We were running through some plans for our authoring system in ucwise -- > > the one where we use pods and Sail does all of the persistence work for > > us! -- and I have some questions. These involve content data, rather > > than student generated data. > > > First, are there particular wiki pages I should be looking at? I'm > > having trouble finding things that are current, etc. > > > We hope to pass off all content authoring to the existing (or soon to > > exist) step authoring classes. So, those classes will provide a panel > > with a "save" button, e.g., which will trigger the pod getting saved. > > > When the content is changed, the pod guid changes, I assume. > > (Everything from here on out is assumptions, actually). So, our classes > > that point to a particular pod (through a guid) will need a listener to > > be told when that guid changes. > > > And, when the content of a pod changes, other pods that point to it will > > change also -- some of the 'container' pods will get new guids, some > > won't, depending if they are supposed to point to the new updated pod. > > Fine, so all our classes that refer to pods will have listeners, and one > > change might trigger a bunch of guid-change events that we get. (And, > > this might lead to some ugly synchronization issues if multiple edit > > windows are open, but lets ignore that for now). Hopefully we can > > register these listeners with something relatively lightweight -- i.e., > > we don't have to instantiate the full editing UI for all pods in our > > editor at startup. > > > This cascading of new guids to some containers but not all sounds a > > little tricky. How is sail deciding what pods to update? Authoring > > information isn't right (i.e., update all those that are owned by the > > person who authored the change), since a particular author may want some > > containers updated and some not updated. > > > It seems like all updates to a pod will need, at least, some contextual > > information -- i.e., update this pod in the context of this other set of > > pods that might refer to it. If this is the right idea, how is that > > context specified? If it is wrong, what is the right strategy? > > > We also realize that nasty issues are going to come up if you have two > > different clients making edits, perhaps even when happening > > asynchronously. But, we can deal with that in time. > > > -nate > > > -+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+-+=+- > > Nathaniel Titterton [EMAIL PROTECTED] > > Lecturer, Researcher 510-643-4207 > > U.C. Berkeley (329 Soda Hall) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
