ChatZilla > Network Backend
Stuff relating to persistent networks in ChatZilla, not including UI - Bug 27807.
The initial contents of this page are entirely my first thoughts on the subject, and are completely up for discussion. - Robert Marshall 13:47, 8 Mar 2006 (PST)
- Allow user to create/delete their own networks, and manage servers.
- Allow user to modify servers on the built-in networks.
- Allow us to update built-in networks if the user hasn't edited them.
- Don't get confused if a connected server is modified/removed.
- Don't let the user delete a network if they're connected.
- Allow user to reset their changes to built-in networks.
- Allow user to delete built-in networks.
- Allow user to rename networks.
- Allow user to make temporary network persistent.
- Remove prefs when a network is deleted.
- Import and export.
- On startup (initNetworks), load the built-in networks (from the current method of hard-coded calls to addNetwork, or a file in chrome:), then the user's networks from a file in the profile. Keep track of which networks came from where.
- Either keep the data source around and modify it as network changes are made, or rebuild it from client.networks each time.
- Save back to the file when necessary.
- Already tested and used in ChatZilla.
- No Gecko version issues.
- Reasonable APIs.
- Possibly useful if the UI uses XUL templates.
- Both code and the saved file can end up overly verbose and hard to read.
- "Just" XML
- Easier to read than RDF.
- Might be hard to parse.
- mIRC servers.ini
- Widely used, but not guaranteed stable.
- Quite hard to read.
- Not extensible.