Turadg wrote: > I like the plan Scott has laid out. I think Tony can move ahead on > developing the tool and the user interactions above the abstractions > in PasCurnitUtils. For example, there are a lot of quick editors to > write. > > I'm looking forward to seeing this skeleton. In the meantime I'd like > to know more about this statement, if there's time to articulate it. > > "The move to OTrunk/EMF will be more fundamental than just redesigning > the Pod system. In OTrunk/EMF there might not be a need to have > something called a Pod. Most of the functionality would be there, it > would just be accomplished by multiple parts of the system working > together." > I think it is easiest to see with an example. > Would OTrunk/EMF allow for distributed authoring and versioning? Re- > use and remixing? > OTrunk/EMF does allow this. I think the way to think of it is like the .java files for Java. The java compiler and runtime does not explicitly support distributed authoring and versioning. However there are multiple ways to do distributed authoring and versioning of .java files.
Similarly to Java, OTrunk/EMF provides the adressing and id'ing supports to enable distributed authoring and version. It is up to an external system to actually manage it. We are currently using Subversion to maintain a repository of OTrunk examples, this is available online so people can easily run them. We will probably extend this so there will be a repository of OTrunk files which are used in schools. We are also using the DIY to store OTrunk files, and that functionality will be extended in the near future. For reuse and remixing, this part of OTrunk hasn't been pushed much yet. It is integral to the design. However just like Java it is up to the person who is designing the system which uses OTrunk to make sure it is reusable as possible. The key piece that hasn't been pushed is splitting the content into multiple files, and the mechanism to find dependent files. But that part is coming and I hope it will be available before October. The part I'm working on now is the "overlay" system. User data is currently stored as an overlay on top of the authored data. I'm going to extend this overlay mechanism so it can support multiple layers of overlays. We will then use that to support localization. The bottom layer will the be initial authored content, the next layer will one of many localization overlays, and the top layer will the user data. This will make it possible to localize any part of the content, but still be able to change the "unlocalized" parts in a single place. Here is a continuation on with the comparison to Java, I wrote it and realized it wasn't really relevant. You might find it interesting. The key parts that Java has to support distributed authoring, versioning, resuse, and remixing is the package naming and class naming. As can be seen after you've used Java a while, these things do provide enough control to maintain over time an application consisting of interdependent parts. The main things missing are packaging classes together, and fine grain control over dependencies between packages. The OSGI system used by Eclipse adds these features. Maven tries to do something similar but it is missing the fine grain control over dependencies between packages. > Also, I understand Scott's statement, "The longer we hold off > switching to OTrunk the easier it will be" but want to add that on the > other hand the longer we wait the deeper and broader the impact of the > switch. So let's keep this ball rolling. > I agree. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
