LiangliangSui opened a new issue, #1412: URL: https://github.com/apache/incubator-fury/issues/1412
## Is your feature request related to a problem? Please describe. 1. ClassId is allocated using `ClassIdAllocator`. The ClassId allocation task is separated from `ClassResolver`. `ClassIdAllocator` is referenced in `ClassResolver` to reduce the complexity of `ClassResolver`. 2. The interface is exposed to users through the Fury class. Users can obtain a ClassId through the interface instead of specifying it at will (specifying it at will may trigger an exception) ## Additional context > Could you elabrate more the ClassIdAllocator? I'm not sure how it handle such an situation: there are three libraries and one client of three libraries. Every libraries has some classes to register, but they can't assume the register order since they don't know which will be registered first, so they use specified class id for such registration. If the client has two versions, the first version use library1 and library2, and the second version use library1 and library3. Then the registered ids in library2 should be left here, those ids shouldn't be used by library3. Will the ClassIdAllocator handle such cases? The purpose is to retain the ClassId registered in lib2. Can we define such an interface such as `allocateClassId(short beginClassId)`? This way the user can specify the starting position of the ClassId. If the user does not specify `beginClassId`, Fury will take over the entire ClassId assignment. That is, exposing two interfaces to users ```java Fury#allocateClassId(short beginClassId) Fury#allocateClassId() ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
