Jeff wrote: >> >> I'm not saying 'don't use CORBA'. I'm saying that the storage medium >> should always reflect what is happening in the working medium (CORBA). >> This is first of all important in case there is a catastrophic failure. >> And I think the working medium can glean information from the storage medium, >> such as who owns a file and who can use it. > I definately agree that the permanent storage should reflect what is happening on the CORBA level. However, I don't really think that managing it via the unix filesystem is the easiest way, since this seems to imply that every remote user who connects will have to be associated with a group on the local filesystem, so that vsh can determine what nodes are available. 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? I think we have a lot of common ground on how things should work, we just need to work out the implementation of those things :-) > It's just a suggestion. If you really have a way to make a distributed > pseudo-filesystem, I'd like to hear more about it and get some opinions from > the others. 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. 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. 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. 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. Does anyone have any suggestions/comments/criticisms? Brad