> At the moment we have three top-level interfaces to maintain in > Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed > to support new options, FOPs or other functionalities, we mostly have > to do the work 3x. Often one of the interfaces gets forgotten I think the picture's a bit more complicated than that. When core features are added, supporting them often requires work in Ganesha and/or Samba as well as GFAPI. Indeed, those are often the only things driving that core work, and the results aren't even accessible via FUSE. In those cases, the technical underpinnings of our FUSE translator won't matter at all. Even when FUSE *is* involved, the work necessary to update xfuse will still be non-zero. Adding a feature to GFAPI doesn't magically add it to every GFAPI-based interface. We'll still have to do a lot of work 3x, and I bet we'll still forget to update them all sometimes. > Yes, there are definitely a lot of features that we need to add. That's the key. While I like the idea of switching to an xglfs-based solution in principle, I think we need a clearer picture of what work still needs to be done *before* we can make more concrete plans. Does every kind of notify (including that GF_EVENT_AUTH_FAILED hack) work the same in xglfs as now? Do graph switches work the same? What about performance or memory use? When we know those answers, and more that might fall out from running a prototype through our existing regression tests, then we can weigh that against the improved maintainability of the newer code. Until then, we're kind of guessing. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
