Closed Manason closed 4 months ago
I can see the advantage of this being pushed to the server side but I think this might be a case of the juice not worth the squeeze in terms of performance sending large amounts of data across the network as well as the client needs to know where they all are anyway to interact with them.
The dynamic garage registration is definitely needed though as there are quite a few resources (especially house garages) that create/remove garages at run time.
To be dynamic it needs to be server sided though, no? Since we'll offer exports to add/overwrite and maybe even delete garages, it cannot be static. The data isn't that much as garage tables are small and it's only loaded once on connection, which would be the same as the server sending the shared config file. So number of bytes across the network shouldn't change.
I can see the advantage of this being pushed to the server side but I think this might be a case of the juice not worth the squeeze in terms of performance sending large amounts of data across the network as well as the client needs to know where they all are anyway to interact with them. The dynamic garage registration is definitely needed though as there are quite a few resources (especially house garages) that create/remove garages at run time.
To be dynamic it needs to be server sided though, no? Since we'll offer exports to add/overwrite and maybe even delete garages, it cannot be static. The data isn't that much as garage tables are small and it's only loaded once on connection, which would be the same as the server sending the shared config file. So number of bytes across the network shouldn't change.
Yeah I can see that argument. Doing it this way makes it easier to eventually push changes to a sql table if needed.
Inspired by qbx_management implementation of a similar feature