Bug #53
Use NetworkId rather than a string to define networks
0%
Description
Right now, networks are identified by their network name throughout Quassel. This is a bad idea, since networks are user-defined strings which might change over time (for example by renaming them in the network settings dialog). We should have a unique NetworkId instead that can then be mapped to the current name for display. This would also make stuff in the network settings dialog much easier (where right now we have a bunch of ugly code tracking renames and substituting strings).
A unique NetworkId is readily supplied by the storage backend (as soon as we have added methods for requesting them), so other than changing a lot of method signatures, it shouldn't be too complicated to implement this.
EgS: You might want to watch out for this while you are redesigning Core :)
History
#1 Updated by Anonymous over 17 years ago
oh yes indeed... :)
#2 Updated by EgS over 17 years ago
actually it's not as straight forward as thought...
currently NetworkNames are used in two different ways:
1. internal identification of the network
2. user representation of the network
The first one can be changed easily. Though for the latter one the question comes to mind: where to store the networkname?
If we pack id and name together in a struct we have to make sure they are synchronized throughout a quassel environment. Therfore I think it's easy to make the networkname available from the global data thats automagically shared.
Since this is still in a work in progress state, the switch to networkids is delayed until then.
I hope this won't become a classic hen / egg problem...
#3 Updated by Sputnick almost 17 years ago
Networks are identified by a NetworkId everywhere now (if I have missed something, please add a note);