> I am just wondering what is the long-term plan here. Do we plan to
handle both prefix/simple code-path with the V1 classes? Or do we plan
to keep both of the classes side by side? Do we plan to avoid duplicated
code, or it's not possible? And what can we do to minimize the new
technical debts?
I reviewed most of the feature code during past time. From my personal opinion,
it will increases complexity if we support simple/prefix layout at the same
time under original logic. As prefix layout uses different table and have the
different FS path construction logic. So using a new V1 class for prefix layout
implementation will be a good way to push forward on this feature. We already
reuse some common code loigc during implementation, but I'm sure there could be
more other code lines can be reused. We could have the further code refactor
later I think. Also seems V1 class name looks a little consused and can be
renamed to a more readable name if we don't want to remove V1 class.
Thanks,
Yiqun
On 2021/4/14, 7:35 PM, "Elek, Marton" <e...@apache.org> wrote:
External Email
I strongly recommend for everybody to test the feature and check the code.
I tested and -- except some backward compatibility issues like HDDS-5094
-- it worked very well.
I also checked the Java code and I am very surprised by the
implementation. As far as I understand -- but I can be wrong -- both the
production and test implementation is based on duplicating some existing
classes with V1 post-fixes with limited code re-usage.
While I created HDDS-5106 to use more meaningful names (I don't know
what is V1, is our current master is the V0?) I am still worried about
this coding style.
I believe that making the code more maintainable is very important
factor (slightly related task about AWS S3 development and simplicity as
a design choice [1])
I am just wondering what is the long-term plan here. Do we plan to
handle both prefix/simple code-path with the V1 classes? Or do we plan
to keep both of the classes side by side? Do we plan to avoid duplicated
code, or it's not possible? And what can we do to minimize the new
technical debts?
TLDR; I recommend to everybody to check the code (and test the branch).
Thanks,
Marton
[1]
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcacm.acm.org%2Fmagazines%2F2021%2F3%2F250706-a-second-conversation-with-werner-vogels%2Ffulltext&data=04%7C01%7Cyiqlin%40ebay.com%7C7767b46a25be4a660a1508d8ff3974ef%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637539969536472439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NNWShEngcq5VN%2F93yi9uaTP2QsuzHrdN7%2Fn4LMs7L%2FI%3D&reserved=0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional commands, e-mail: dev-h...@ozone.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org
For additional commands, e-mail: dev-h...@ozone.apache.org
