Bug #53

Use NetworkId rather than a string to define networks

Added by Sputnick about 13 years ago. Updated over 11 years ago.

General / Unspecified
Target version:
Start date:
Due date:
% Done:


Estimated time:


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 :)


#1 Updated by Anonymous about 13 years ago

oh yes indeed... :)

#2 Updated by EgS about 13 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 over 12 years ago

Networks are identified by a NetworkId everywhere now (if I have missed something, please add a note);

Also available in: Atom PDF