Hi Bookkeepers, I am trying to draw the best roadmap with the goal of consolidating ExplicitLAC feature. Currently I have two big topics: - on the reader side I would like enable new API users to leverage ExplicitLAC, transparently (no new configuration, now readflags, no explicit API calls) - on the writer side make ExplicitLAC work better with DEFERRED_SYNC (like having a background force() together with the sending of ExplicitLAC)
Currently I want to spend time mostly on the reader side, because it will enable new clients to use ExplicitLAC. My current (new) idea is to add a new flag on readEntry() RPC with which the client asks for the ExplicitLAC together with the entry. With this change we can support backward compatibility easily. New clients will add that flag and they will be able to read the new optional ExplicitLAC field. Old bookies will ignore the flag. Old clients won't ask for ExplicitLAC. If there is no ExplicitLAC this new feature won't add costs on the wire. After this discussion on the ML I will post a BP, if we agree that this approach makes sense. I have started to draft a prototype yet, I would like to hear your opinion (as usual I have very limited time) Regards Enrico
