On Thu, Dec 6, 2012 at 10:38 AM, simo <idra@xxxxxxxxx> wrote: > On Thu, 2012-12-06 at 10:16 -0500, Scott Lovenberg wrote: >> On Thu, Dec 6, 2012 at 7:37 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: >> > 1/ Should we switch this code to use a config file of some sort instead >> > of this symlink? The symlink would probably be more efficient, but it >> > is a little odd and might confuse people. It also might make it hard to >> > expand the idmapping interfaces later. >> >> Please no symlinks. We could end up with something like alternatives >> (/etc/alternatives) where you need a utility to track and change >> symlinks pointing to symlinks. I don't even know where java is on my >> machine or which JVM I'm running. Symlinks have a tendency to turn >> into symlink farms. Look at your PAM install, it's a bunch of links >> to a single file on most installs. That way lies madness and dragons. >> >> I think most people are comfortable with config files and they're >> intuitive. Also, is anyone at any time going to be using more than >> one mapping interface? > > Probably not, which is why a symlink is all we need. > I think starting with a symlink is fine, I do not particularly love it, > but makes a lot of stuff simpler for starter. > Having to parse a config file at each program invocation (for utilities) > adds up in latency and also requires YACF (Yet Another Config File) > where all you do is say: use plugin X, or a very complex version of a > symlink. > > Now if you need to actually configure something then yes we could move > to use a config file eventually. > > But unless you already know there is something the cifs utils (*not* the > plugins) need to configure then it seem a lot of overhead both in terms > of coding that needs to be done, file formats to choose and associated > bikeshed, and runtime churn. > > Simo. Simo, those are all great points. FWIW, even though I don't like the idea of symlinks, I'm inclined to agree with you that in this case it's the correct way to go. -- Peace and Blessings, -Scott. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
