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)

Requirements

• 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.

Possibilities

• 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.

Logic

• 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.

Format

• TextSerializer
  • Already tested and used in ChatZilla.
  • No Gecko version issues.
  • Simple.
• RDF/XML
  • 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.