[Pipet Devel] Choice of ORB implementations

[Brad Chapman]

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