[SERVER-70429] Remove MongoDB embedded sdk from the codebase Created: 10/Oct/22 Updated: 16/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jason Chan | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Build
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 36 | ||||||||||||||||||||||||
| Description |
|
PM-1605 originally EOL'd MongoDB Mobile, but we decided to keep some of the embedded SDK builds around as the maintenance burden was expected to be low. This ticket is to revisit the idea of removing them completely as the service architecture team looks to do some refactoring projects, one of which includes the ServiceEntryPoint which includes service_entry_point_embedded.cpp and its header file. Removing these files will also mean there will be less developer burden on having to implement empty stubs in a lot of the *_embedded.h/cpp files whenever a function is added to the base class. For instance, the Replication team currently has to add a stub to replication_coordinator_embedded every time a new member function is added to replication_coordinator.h |
| Comments |
| Comment by Alex Neben [ 21/Jun/23 ] |
|
A related ticket shows us deleting the test. If we go to the commit that did that that the test runs this target and this target. Looking in scons we see embedded-test here and embedded-dev here. So we want to delete all the code for those two as well as any library that is only for them. |
| Comment by Alex Neben [ 31/Jan/23 ] |
|
> The concept would not be terribly difficult to reimplement or resurrect if we found a real use case again. I think we should get rid of it from the codebase then. |
| Comment by Daniel Moody [ 28/Jan/23 ] |
|
well nothing will be exercising it so its likely to atrophy. The points mentioned here do make it seem pretty cumbersome. The concept would not be terribly difficult to reimplement or resurrect if we found a real use case again. Alternatively we could try to make a more separated canary target to keep it on life support, but one that developers wouldn't need to deal with. |
| Comment by Alex Neben [ 28/Jan/23 ] |
|
daniel.moody@mongodb.com do you have any thoughts here? My opinion is that we can remove this as long as we keep the scons code to build dynamic sdks in the future. |
| Comment by Louis Williams [ 11/Oct/22 ] |
|
See ongoing discussion in |