Projects: TEEMSS2 : Distributed Object Store
This page last changed on Sep 08, 2004 by scytacki.
(2 weeks more design) This doesn't need to be implemented until later summer, right? But the design will influence collaboration aspect of the activities, and the importing and exporting from each manufacturer. And it influences the portal design.
Collaboration?? what amount of collaboration do we want and can we support.
This page is under serious construction. Don't expect to be able to understand it easily. Basically it is a colleciton of ramblings on this part of the system. It hasn't materialized into a design yet. At this point I would say it needs a two weeks of full time work or 1 month of my 50% time to turn it into a more concrete design:
It could take much more than 5 days, but I think I could set that as a deadline for working on this and be happy with what I had after that amount of time.
This is the core technology of the whole project. I think this is what is most likely to live beyond the project and be useful to handheld probe and curriculm companies. If it is designed right it can separated from waba and java. One the palm it can just be a format for a palm database file, or pocketpc database file/program. On the desktop it will have a database format that could be used by java libraries, php libraries, or other native libraries.
On a palm a dynamic group must be setup at the beginning of class. This way data can be ascociated with each user.
It would also be ideal for every palm to have every users data. That way any student can pickup any palm. This would need to be limited somehow. At least on the level of the school. Perhaps at the level of the class. Or if that doesn't fit then the level of the student.
Also any dos objects that are saving user data need to support multiple users accessing those object. And each user or group needs their own view of those objects.
The main idea is to have a Class or Interface that objects can extend and then they can be saved in this system. When they are saved their code is saved too. And then when they are used their state and code are moved around to where ever they are need. The objects do not need to worry about these details of being moved around from here to there. And if they need another object it will be automatically found and made available. Also these objects have a formal version of users so permissions can be implemented. Finally they also have version control. This is an abstraction that I always find myself wanting.
It has its own synching mechanism. That makes the data available internet wide.
Things that I've found that are similar to this are DHTs or distributed hashtables. These is a recent movement that is documented a little on the tels site. Look under the distributed heading of this site: http://docs.telscenter.org/display/SAIL/Development+Technologies
I have not found an existing technology that does everything we need. So what do we need:
Here is a matrix of these features and a few technologies:
it might be possible to divide this into parts.
!If we base it on a two way unsecure data-transfer and caching system like:
Is there another option besides using that as a base? the main problem is dealing with the unsecure storage, and efficient dependency usage. We can do efficiet dependencies if the server tracks the clients and the clients track their updates. subversion does the second half of this. The first half might make p2p hard.
So essentially it seems like splitting it this way is ok. now we talk about the requirements for each part of the split.
An object database might have the dependency management built in. But this needs to linked with the transfer code, so probably we'll need our own dependency management.
I originally thought we would need a full ACL(access control) type system, so I started working on an elaborate key system to support this. Here was the first pass at that. However now I think we don't NEED that. It would be nice but probably all we really need is what I listed above: signed content, and encrypted results. Data shared between users can be unencrypted but signed by the creator. For p2p data sharing there won't be a way to keep student A from replacing students B data. But a user would know the data wasn't created by B because there is no way for A to sign it. So in this system only the users public keys need to be protected. And that can be handled if the list of keys are signed by a trusted key.
|Document generated by Confluence on Jan 27, 2014 16:43|