Hi all. I just made a huge commit to: sail-core Pas Learner Runtime pas-commons-apps pas-author-runtime WISE Project Converter
I wish we had a changeset viewer I could refer to. Still waiting to here from Cenqua. The changes that touched the most files were the introduction of generics. Putting generics on Rim and Sock had the broadest impact. There are much fewer casts now and more is caught at compile-time. For example, the MemoryPersistanceTest had a test to check that assigning adding a value incompatible with a rim's shape will through an exception. But now, you can't even compile that code because it violates the generics inference of the Rim class's methods. Comments welcome on OWL-265. Another change to be aware of is to the PodUtils.nextPod() method. It used this serialization scheme that wasn't guaranteed to avoid collisions across multiple invocations. It worked before we had the authoring tool because all pods were made at once, but with the authoring tool a new pod can be introduced in another JVM and since the method used a static instance counter a collision was actually likely. Now nextPod() sets the last 12 digits of the pod UUID to a random number. Along with a few other simple bugs in the PAR, I think I've fixed OWL-257 and OWL-263. While I was debugging the pod assembly system, I went back to the pod model page, http://www.telscenter.org/confluence/display/SAIL/Pod+model Scott has this comment there: > After working with this model a bit. I really like to remove the > assembly-calls. Using these makes it difficult to parse the content without > "assembling" it. This means the content is not declarative. > > I can see two reasons for the assembly calls: > 1. to deal with references to non-local objects. There needs to be a way > to reference an object that is defined in another Pod. Assembly calls were > probably the easiest way to make this work with XMLEncoder. There are other > ways to do this that would be much easier to parse. > 2. to make the pod more reusable. Because part of the pod is stored > unassembled in theory it should be possible to reuse the unassembled pod, by > just changing the assembly calls. But this level of reuse has not been used. > To reuse an assembled pod it just needs to be cleaned of its assembled > parts. > > If we really want to maintain number 2, it would be possible to maintain > this reuse in a declartive/templated way. However, even in this case it > would be best to store a fully assembled pod in the curnit. The unassembled > pod could be used by the authoring system and at publishing time the pod is > fully assembled. > I agree and hope we can abandon XMLEncoder. I don't know much about the alternatives anymore, but EMF or JAXB seem like they may be made to work. So I made a ticket and assigned it to Scott, XML binding expert, in the hopes he'll have any time to think about it. http://www.telscenter.org/jira/browse/OWL-264 Also while I was working, I came to think that replacing our UUID system with URIs is really important, should be done sooner than later, and actually may not be so hard. The current UUIDs can easily be turned into URIs and the PodRegistry can figure out where to get things when they're needed. Moving everything to a web resource makes versioning much simpler, no edit collisions. As I think I said earlier, I don't expect Pas will have pod-level versioning in production in '07. Instead we should focus on the curnit-level versioning. On the side, we can reassess versioning and the persistence format altogether. Take another trip to the drawing board with a web-based ReSTful perspective I think will greatly simplify our designs and shorten development time. I ran the unit tests on all the stuff I committed, but I haven't heard from Continuum yet and of course our unit tests don't cover much anyway. So if there are bugs that you encounter with my commit, please let me know and I'll get on them quickly. -Turadg --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
