27807 - Network/Server information needs to be saved externally (not in prefs)

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect, P3)

Description

[Hervé Renault]

in function
function initHost(obj)

please add :

    obj.networks["ircnet"] =
        new CIRCNetwork ("ircnet", [{name: "irc.twiny.net", port: 6667}],
                         obj.eventPump);

that's what i did with my M13.
IRCNet is used by a lot of european people.
thanks.

Comment 1

[Robert Ginda]

actually, networks and servers and such need to be moved into prefs, so they're
not hardcoded in the app itself.  Another thing I plan to get to RSN.

Comment 2

[Robert Ginda]

*** Bug 42193 has been marked as a duplicate of this bug. ***

Comment 3

[Robert Ginda]

mass marking chatzilla bugs future

Comment 4

[David Krause]

*MASS SPAM*

Changing QA contact on all open or unverified ChatZilla bugs to me, David
Krause, as I am now the QA contact for this component.

Comment 5

[Jacob Steenhagen]

I know chatzilla has been placed on the back-burner, but perhaps the original
request in this bug could be completed (adding ircnet to the list of servers
accepted).  A new "enhancment" bug could then be created for moving to prefs
(which would depend on bug 23265).

Comment 6

[David Krause]

I was in the process of whipping up a patch for static.js but then I discovered
that irc.twiny.net doesn't resolve.  I found out that there is a irc.twiny.org
but when I tried to connect I got 'no route to host.'

Does anyone know of another good ircnet server?  We should probably have it in
the file since it is one of the Big Four Networks (EFnet, Undernet, DALnet,
IRCnet). If so make a patch for static.js and we'll get rginda to approve it and
timeless to check it in since he's not affected by Netscape.

Comment 7

[Hervé Renault]

strange... irc.twiny.org is a reliable server. many people use it here. maybe
you encountered a temporary problem.
anyway, there's also ircnet.grolier.net which is reliable.

Comment 8

[Robert Ginda]

*** Bug 79345 has been marked as a duplicate of this bug. ***

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 98870 has been marked as a duplicate of this bug. ***

Comment 10

[Robert Ginda]

Alternatley, this could be a special bookmarks folder, like IRC->Networks. 
Anything under that bookmark folder would be takes as a network.  Servers,
channels, and users could be added below the network.  Maybe not.

Comment 11

[etoffi]

i like the above idea. very nice.

Comment 12

[Samuel Sieb]

*** Bug 107246 has been marked as a duplicate of this bug. ***

Comment 13

[David Krause]

Remove myself from QA of 33 open Chatzilla bugs and change to default QA
contact, since I have no way to verify these easily.  Still no working Mozilla
on my primary platform and it doesn't look like it will happen anytime soon. :(

Comment 14

[Benoit]

Now that we seem to have some kind of pref panel in bug #23265 this can be
revived as well.

It would be wonderful if we could import a server list in the mirc format
described here : http://www.mirc.co.uk/help/serverlist.txt

For example, the current servers.ini provided with mirc :
http://www.mirc.co.uk/servers.ini

This way it wouldn't be needed to update chatzilla when a new network comes up
or changes his name (like bug #188075 or bug #135926 )

Maybe I should open a new RFE for that ?

Comment 15

[James Ross]

I think importing mIRCs server list file should rpobably be a seperate RFE, and
should rpobably depend on this one since you can't import without something to
import to. :)

Comment 16

[Koike Kazuhiko]

*** Bug 197154 has been marked as a duplicate of this bug. ***

Comment 17

[Koike Kazuhiko]

*** Bug 197159 has been marked as a duplicate of this bug. ***

Comment 18

[James Ross]

During a discussion of this on IRC, the possibility of using XML to store the
networks arose. A possible layout for such a file is here:
http://www.warwickcompsoc.co.uk/~silver/temp/cz_nets.xml. Even without it being
XML, it was generally agreed than a separate file was better than storing it all
in one or more prefs.

One possible problem (other than bloat from simply being XML) is that to
parse/serialize XML requires the xml-extras extension to be built. While it is
built in the Mozilla Suite and Firefox releases, it is still an optional component.

Comment 19

[Ian Neal]

Would using RDF require the use of any extra extensions?

Comment 20

[James Ross]

I think RDF is far too verbose for this, plain XML is all we need. I'm also not
quite sure how you *do* anything with nsIRDFXMLSerializer.

Comment 21

[Samuel Sieb]

How about using the mirc format?  It's a little wierd, but functional enough.

Comment 22

[:Gijs (he/him)]

(In reply to comment #21)
> How about using the mirc format?  It's a little wierd, but functional enough.
> 

I disagree. The mIRC format doesn't allow for storing whether or not a server uses irc securely, which we do want to store. It's fine to have a convertor of some sorts, but as mentioned in comment #15, that should probably a separate RFE.

Currently there's work done on adding a plaintext <-> js object serializer. I'm pretty sure we could also use that for this problem. :-)

Comment 23

[James Ross]

I'm planning to try using the serialiser on this.

Comment 24

[James Ross]

Attachment: [not for checkin] Store networks in serialized text file

This is what I've got currently, for the initial change to persisted networks. This patch also updates the text-serializer to support booleans and null, which is necessary for persisting the data.

All this does currently is create the networks.txt file with the existing pre-set list of networks if it doesn't exist, and loads it if it does. No changes made in the client are saved. Changes to the file will be loaded, however, and I've checked this works.

Although this patch doesn't do much, this is definately the time to check you like how I've done the persisting/etc., especially the whole client.networks synced with client.networkList thing.

Comment 25

[Rob Marshall [tH]]

I don't really like how this prevents us changing the default server list for existing users, but I haven't really thought much about how hard that would be.

Also, the syncing stuff doesn't seem to deal with deleting networks. Is this planned?

Comment 26

[James Ross]

Those are both issues I know about; the deleting is easy to do, but the default list is much harder. I've been pondering how to do it, and can't really come up with a good way to do it.

Comment 27

[James Ross]

Attachment: Load networks.txt and "apply" to built-in networks

Ok, this patch doesn't save any files (as no saving is needed yet), but it loads networks.txt and will apply it to the built-in list. This means that new networks can be added both by networks.txt and ChatZilla's list without problems, and networks.txt can even hide a built-in network (or networks).

Comment 28

[:Gijs (he/him)]

Comment on attachment 216968 [details] [diff] [review]
Load networks.txt and "apply" to built-in networks

>+    var builtInNames = keys(networks);

...

>+    /* Flag up all networks that are built-in, so they can be handled properly.
>+     * We need to do this last so that it ensures networks override by the
>+     * user's networks.txt are still flagged properly.
>+     */
>+    for (var i = 0; i < builtInNames.length; i++)
>+        networks[builtInNames[i]].isBuiltIn = true;
You're using keys() to get an array of names (which takes a for-in loop), and you use that once, as far as I can tell - why not have a for-in loop here? Seems simpler...

I think the rest is okay, but I can't say I checked it very thoroughly. This just jumped at me or something... :-)

Comment 29

[James Ross]

If you look just above the 2nd bit of code you quoted, you'll see that the keys for |networks| is changed by the user's loaded networks. I wanted to keep a list of the built-in ones only, then make sure even if the user had replaced it we still considered it built-in (or the delete behaviour wouldn't work).

Comment 30

[Samuel Sieb]

Comment on attachment 216968 [details] [diff] [review]
Load networks.txt and "apply" to built-in networks

Sorry for the long wait.

>+     * We need to do this last so that it ensures networks override by the
override -> overridden

>+        listNet.servers = new Array();
Is this line supposed to be here or at the end of the previous if?

>+        // Update server list (adds all servers if new).
This comment seems to imply that the previous line shouldn't be there.

>+    // Remove and no-longer existing networks.
and -> any

>+        if (i in networkMap)

>+            // Note: don't do i++ here because we've removed the item.
>+            client.networkList.splice(i, 1);
You can't do the splice here or else you need to use two indexes. If you don't do i++ here, you will mess up the previous test as i will be pointing at the wrong entry in networkMap.  If you do i++ here, you'll have the wrong index into networkList.

Comment 31

[James Ross]

Attachment: [checked in] Fix review comments

This corrects the typos, and the comment next to the listNet.servers init. It also uses two indexers for the deleted network removal.

Comment 32

[James Ross]

Comment on attachment 219112 [details] [diff] [review]
[checked in] Fix review comments

Landed this patch. On to the next phase!

Comment 33

[James Ross]

Ok, I think the base work is done here. The remaining work belongs in bug 239080.

--> FIXED.

Comment 34

[Matěj Cepl]

It could be probably worthy to mention http://glenjamin.co.uk/chatzilla/networks/ which generate a list of networks for you.