On Thu, Sep 20, 2012 at 2:05 AM, Troy Benjegerdes <[email protected]> wrote: >> Perhaps...once the following conditions are met: >> >> 1. we've either: a) resolved the local/distributed debate, or b) found >> a way to do local-only now without precluding distributed from being a >> future strategy (the complications of doing local-only--sans a >> cohesive strategy for implementing distributed fifos in the >> future--have been discussed at-length on this list in the past); > > Was there any sort of resolution, or did we just have a stalemate > of opinion? >
It seemed rather unresolved when I last paid attention... > I see the point of having a distributed toolkit for heterogenous > systems, and there could be some really interesting and powerful > stuff you could do with distributed unix sockets protected with > filesystem ACL's. (Say collaborative editing for a document, ala > Etherpad, for instance) > > But in the meantime, the perfect is the enemy of the good, and > lack of functioning sockets makes it a real pain to use the amazing > distributed toolkit we *do* have for things using it as the rootfs > for a 'cloud' based operating system. > Point taken. My _hope_ would be that local-only could be architected in a manner forwards-compatible with distributed sockets/fifos. If that goal cannot be met, then, alas. I concede the good is likely better than the perfect in this context. > What's the roadmap for first, local-only unix sockts, and then > defining the right rpcs so the code might someday be written? Well, at least from my perspective, a big issue is: how do you handle allocation? Waiting for standardization of a next-generation vnode create RPC would be ideal, however would likely require you to wait an unacceptably long period of time. I suppose you could take the disconnected-like approach (of doing it as a purely-local vnode and dirent allocation--that gets merged upon parent dir DV change), although that necessarily involves some rather unfortunate collision resolution semantics... -Tom _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
