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

RESOLVED FIXED in Future

Status

Other Applications
ChatZilla
P3
normal
RESOLVED FIXED
18 years ago
6 years ago

People

(Reporter: Hervé Renault, Assigned: James Ross)

Tracking

(Blocks: 2 bugs)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cz-0.9.73])

Attachments

(3 obsolete attachments)

(Reporter)

Description

18 years ago
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.

Updated

18 years ago
Status: NEW → ASSIGNED
Summary: please add IRCNet in the prefs. → Network/Server information needs to move into prefs.

Comment 1

18 years ago
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.

Updated

18 years ago
Blocks: 23265

Comment 2

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

Comment 3

17 years ago
mass marking chatzilla bugs future
Target Milestone: --- → Future

Comment 4

17 years ago
*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.
QA Contact: rginda → David

Comment 5

17 years ago
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

17 years ago
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

17 years ago
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

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

Updated

16 years ago
No longer blocks: 23265

Updated

16 years ago
Depends on: 23265
*** Bug 98870 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
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

16 years ago
i like the above idea. very nice.

Comment 12

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

Comment 13

16 years ago
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. :(
QA Contact: mozilla → samuel

Updated

15 years ago
No longer depends on: 23265

Comment 14

15 years ago
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 ?
(Assignee)

Comment 15

15 years ago
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

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

Comment 17

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

Updated

15 years ago
Blocks: 116803
(Assignee)

Updated

14 years ago
Blocks: 239080
(Assignee)

Comment 18

14 years ago
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

14 years ago
Would using RDF require the use of any extra extensions?
Product: Core → Other Applications
(Assignee)

Comment 20

13 years ago
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.
(Assignee)

Updated

12 years ago
OS: other → All
Hardware: Other → All

Comment 21

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

Updated

12 years ago
Blocks: 135926, 227366
(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. :-)
(Assignee)

Updated

12 years ago
Blocks: 314617
(Assignee)

Updated

12 years ago
Summary: Network/Server information needs to move into prefs. → Network/Server information needs to be saved externally (not in prefs)

Updated

12 years ago
Depends on: 296702
(Assignee)

Updated

12 years ago
Status: ASSIGNED → NEW
(Assignee)

Comment 23

12 years ago
I'm planning to try using the serialiser on this.
(Assignee)

Updated

12 years ago
Assignee: rginda → silver
(Assignee)

Comment 24

12 years ago
Created attachment 216467 [details] [diff] [review]
[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

12 years ago
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?
(Assignee)

Comment 26

12 years ago
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.
(Assignee)

Comment 27

12 years ago
Created attachment 216968 [details] [diff] [review]
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).
Attachment #216467 - Attachment is obsolete: true
Attachment #216968 - Flags: review?(samuel)
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... :-)
(Assignee)

Comment 29

12 years ago
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

12 years ago
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.
Attachment #216968 - Flags: review?(samuel) → review-
(Assignee)

Comment 31

12 years ago
Created attachment 219112 [details] [diff] [review]
[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.
Attachment #216968 - Attachment is obsolete: true
Attachment #219112 - Flags: review?(samuel)

Updated

12 years ago
Attachment #219112 - Flags: review?(samuel) → review+
(Assignee)

Comment 32

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

Landed this patch. On to the next phase!
Attachment #219112 - Attachment description: Fix review comments → [checked in] Fix review comments
Attachment #219112 - Attachment is obsolete: true
(Assignee)

Comment 33

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

--> FIXED.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Whiteboard: [cz-0.9.73]

Comment 34

6 years ago
It could be probably worthy to mention http://glenjamin.co.uk/chatzilla/networks/ which generate a list of networks for you.
You need to log in before you can comment on or make changes to this bug.