Brad Chapman wrote: > > We definately need to work out how this should work, but I'm still > gunning for having stored loci have a tag that reflects their group, > and then have another storage file that associates remote logins with > groups. This is analagous to the unix filesystem, but doesn't use it, > because I feel like then the vsh user will have to configure their > local filesystem outside of a running vsh implementation, while the > other way will allow this configuration within a vsh (as an extension > of your development environment idea). We could also tie the vsh > development environment with assigning groups in the local filesystem, > but it seems like we are abusing the meanings of groups to make them > extend to remote users. Isn't all the unix group and permission stuff > meant for configuring a local environment, and not a remote one? You're right that the Unix authentication and file systems cannot manage a distributed system like ours. > I've been reading into this more. I don't think the naming service > will work for a distributed pseudo-filesystem. Although it is > organized in a tree-like structure like the filesystem, it is meant > for publishing corba objects. Each subnet or node that is available on > a computer will not be a different corba object, but rather will be > represented as XML, so we can't publish these objects in a naming > service (or any other service for that matter). This is why I think > the way things should work is that the naming service is used to > locate remote hosts (like dns) and then you should query them to see > the full list of nodes that are available. I while ago I mentioned JungleMonkey: http://www.junglemonkey.net/ I think it is a distributed filesystem like Napster (I know little about Napster). I'd like us to take a VERY SERIOUS look into making a Napster-like system. We can set up a central server at The Open Lab that can register every node in every VSh system on the Internet. What do you think? > In addition to this, we could also utilize the trading service, > which publishes objects by description (rather than by name). So a vsh > instance could publish their connection object, and then associate > the description of the object with the publically available nodes > (along with other information about the computer such as processing > power, etc.). Then a user could search for a particular subnet or node > (a particular program) and find out where it is available. Perhaps a bit like Napster. I like the idea of cumputers being registered for power, etc. > So, stealing some analogies from the corba documentation, our > naming service would be like the white pages, where you can find other > computers by their known name, and the trading service would be like > the yellow pages, where you can look up the computers by the services > they offer. It still would require a central registry, like DNS and.....hmmmm.....could it be....NAPSTER?! :-) > I know this isn't your vision for how things should work, but > seems to implement the same ideas, only using already designed corba > services. You know more about the services CORBA can offer. Actually, what you described is more like an earlier vision I had for Loci, where there was a central 'hub' for locating loci. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+