I love the eSDT idea. The big problem for the current SDT is that we practically can not change the existing field in the SDT (of course, we can delete or update the old data though) even though we want to refactor the filed or field name itself. It also makes us to develop new sdt slower (because we have to carefully think about the sdt fields and predict every single possible problem that would occur in the future at the design level). So the eSDT would solve the kind of problems for us.
Several things I concerned was that: * In the schema level evolution, does the field change reflects the old data in the server too? If so, developers are supposed to carefully think about deleting fields. What if we decided some fields in the existing data is useless and delete it, but in the future they need the same field data again. Should the system support some backup mechanism? In the client update inconsistency in the Implementation Issues, should the system support an alert mechanism if the old data is received after the server side is updated? This would be not the kind of active alert to let all users know, but just the users who sent the old data after the server was updated. Cheers, Takuya On Tue, 01 Mar 2005 11:57:17 -1000 Philip Johnson <[EMAIL PROTECTED]> wrote: > I've just finished a white paper that outlines an approach to addressing > some of our longstanding problems related to evolution in way we want to > represent sensor data over time: > > <http://hackydev.ics.hawaii.edu/hackyDevSite/doc/evolutionarySDT.html> > > It's also available as a link from the HackyDevSite home page. > > My goal is to implement this mechanism in time for the next stable release. > Before I start ripping away at the guts of hackyKernel, I would appreciate > your perspectives on the following: > > * Do the proposed enhancements appear useful? > > * Are there other enhancements we should consider? > > * Are there potential problems/dangers with the proposed enhancements? > > * Are there important implementation issues I should remember to consider? > > * Do the proposed enhancements appear to address the problems you have > encountered related to sensor data evolution? If not, please describe your > situation so I can think about what else I need to incorporate into the > design. > > Thanks! > > Cheers, > Philip > > p.s. Before I start on this, I am going to complete work on upgrading > Hackystat to JDOM 1.0. This "official" version of JDOM is unfortunately > NOT backward compatible with older versions of JDOM, and so we're going to > need to update a lot of our systems simultaneously. While this is going to > be a pain, the start of a release cycle is a reasonable time to inflict it > on ourselves and we need to do it sooner or later. ================================ Takuya Yamashita E-mail: [EMAIL PROTECTED] ================================
