Excellent points Scott. I'm not much in the loop anymore and was soliciting such issues in my proposal e-mail last week. I got one affirmative reply and a few days of silence, which I thought was consent. But as I think about it, I sent it Thursday evening so that basically worked out to just one whole workday, Friday.
This probably kills the "one pod for Pas" idea. It's a big trade-off. I ran into the rim name collision issue and got around it by prefixing the old rim name with the epoch seconds at its creation. A drawback to this is that the rim name changes with each build. On further thought, I suppose that's completely unworkable. Finding the context of a rim could be helped with some step to rim map. The problem is that steps don't have identifiers in this new scheme. Pod ids were to be step's identifiers. But steps could have identifiers if we wanted. Consider the smaller case of wanting to put a whole activity in one pod. Should we allow this? In that case there would have to be some step naming (for software, not display like the title) to keep them unique and persistent within the one activity pod. Same scheme could be used for the logging. Of course, this "one pod" simplification then isn't so simple. I made the change to make it easier for Tony to develop the authoring tool within hitting snags in working with pods. Given the learner data issues you point out, I think the trade-off isn't worth it. So please go ahead and flip that boolean in the WISE Project Converter. I'd do it myself except I'm not at my dev machine right now and it would be good for someone else to see that code. Hopefully the methods in PasCurnitUtils will be enough to shield the authoring tool from pod matters. Scott, can you also write back to the Replacing XMLEncoder thread? Maybe we can improve pods sooner than later. -Turadg On Jul 23, 8:58 pm, Scott Cytacki <[EMAIL PROTECTED]> wrote: > How does this deal with the user data. > > It used to be keyed off of pod id and rim name. If there is only one > pod, then that means the rim names have to be unique across the whole > curnit. > > Many of the rim names in the old curnit format (one pod per step), were > "undefined1", "undefined2". At least because they were inside of pods > we could identify the context of the rim by finding the pod and doing > our best to parse the xmlencoder for that pod. > > If there is one pod, then I assume that means there will be one giant > xmlencoder file that contains all the steps. It will be pretty > difficult to parse this to figure out the context of a rim. > > Additionally the navigation log was based on the pod id. So with one > pod, the navigation log will no longer be meaningful. Having multiple > pods was a nice abstraction from the specific implementation of pas, > onto which tools like the reporting parts of the sds could be built. > > I agree that the way it was working with multiple pods, and xmlencoder > was not good. But replacing that with a single giant xmlencoder file > will make the situation worse from the student data point of view. > > ScottTuradg wrote: > > Ok, I've gone ahead with the plan. > > Seehttp://www.telscenter.org/jira/browse/PAS-508 > > andhttp://fisheye3.cenqua.com/changelog/tels/?cs=2136. > > > So now curnits spit out by the converter have just ONE pod. All the > > beans go in there. When we figure out a workable system for reuse, we > > can add it in then. > > > The ProjectConverter has a boolean flag for whether to *share* the pod > > among all the beans or let them each have their own. Right now it's > > settable only in code, since we should be careful about switching that > > flag. > > > I made the PasCurnitUtils so it can tell the difference between > > sharing pods and individual pods, but I haven't been able to test it > > thoroughly. Tony, I hope you can add more tests to > > PasCurnitUtilsTest. Good work on making that. > > > I'll write in the other thread on the move methods. > > > On Jul 19, 6:40 pm, "Anthony Perritano" <[EMAIL PROTECTED]> wrote: > > >> right on. i think it will make it easier to built better tools, debug pod > >> serialization problems..etc yes our original reuse plan kinda fades away. > >> but maybe we should think about reuse on the bean level, if such a thing > >> can > >> be done. > > >> -Tony > > >> On 7/19/07, Turadg <[EMAIL PROTECTED]> wrote: > > >>> Tony and other Pas developers, please take a look at this proposal and > >>> let me know what you think. Particularly, what are your concerns? > >>> I'll try to address them. > > >>>http://www.telscenter.org/confluence/display/PAS/Proposal+for+one+pod... > > >>> -t --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
