This is mentioned in the material that we would have a reparsed daemon is userspace which knows how do deal with the overall format and knows how to deal with service specific parts through a plugin model where each service would have its own module. This would make the whole thing easily expandable for future services/subsystems that want to use this mechanism for location redirection.
Afshin Nicolas Williams wrote: > On Mon, Jul 13, 2009 at 03:44:42PM -0700, Afshin Salek wrote: >> This is supposed to be a generic and expandable mechanism. NFS/DFS >> referrals are just primary consumers of this mechanism at this >> point so this is not a protocol specific mechanism to have a per >> protocol extended attribute that are hard coded before hand. >> >> If we want to use extended attributes then we either have to reserve >> some namespace or use an extended attribute with a reserved name as an >> index. It also makes path name reduction very expensive because for each >> component we have to do a lot of extra stuff to see whether we are >> dealing with a reparse point or not and whether that reparse point >> contains the data that we are interested in. > > I'd stick with the ESA as the optimization, but EAs for storing the > referral if you can manage the namespace, else make the symlink thing > not-an-interface and provide a CLI, so you can change the implementation > later. > > Oh, hmmm, I just noticed that the reparse string format is private. But > I see no public interfaces for managing reparse points. Are UIs due > later? If so never mind my comments to date. > > Nico
