Malakh: The current version of the IRC client connects but is very frustrating to use, at least on Safari. The sidebar scroller controls work erratically, and your typed text doesn't automatically appear in the window. Plus the color selections can lead to weird results (and some people seem to object to this.)
Finally, its complaining that we are running an "unregistered copy". Does this mean they expect Money ?! for this less than stellar piece of coding? I would say that we should not directly link to this from the tiki-home page, at least until some of the bugs are worked out. (Or at least advertise that it is not Safari friendly).
I know I was the one that asked for this capability... and I appreciate the effort. But if this is what we can do, then its more a minus than a plus, in IMHO. I apologize.
Oh and a final note... *will* this actually get around the firewall issue? Since it runs client side and not server side? My intuition tells me that it actually doesn't get us around the problem that started us on this merry chase.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ras,
I posted that java irc client. You're right, it may be no better than a stand alone client as far as firewalls go, so I removed that statement. I don't think we'll be able to do anything better unless we can control the IRC server (or even better the machine on which it runs).
I posted some other comments about this in the Admin blog. Its shareware, and thus the messages. It works best with IE and Netscape.
jazzdman
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I put it on the front page, because AFAIK, the only one's who know about the tiki-wiki are active members, or those who search through the forums. I can try posting the other IRC client I found, but it is even more "crippled" and may not work any better with Safari.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm,
Some more searching on the web reveals this :
cgiirc.sourceforge.net
From that website
"CGI:IRC is a Perl/CGI program that lets you access IRC from a web browser ...has many uses ... or to acces IRC when stuck behind a restrictive firewall"
I'll try this one, but again, where would you like me to put the link?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would say that if this runs server side (as a cgi) then it could very well get past the firewall issue. If we can install that on the SF site (don't know what CGI abilities we are allowed) then give it a try. You can put the link on the home page for now, but I was thinking of having a special IRC page anyway to give info about where to go for IRC clients and help, etc. That would be the right place to put the link to our applet(?) anyway, in my opinion. Thanks for keeping looking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, experimentation with cgiirc did not pan out. There are two available clients, one in perl and one in c. For some reason, the perl client craps out trying to create a directory while opening a socket for communication? If anyone wants to take a look at the Perl client (which isn't very well commented) , line 489 of nph-irc.cgi in
/home/groups/o/op/openknights/cgi-bin/cgiirc-0.5.3 is what is producing the error I am seeing.
There are no facilities (for good reason I imagine) for compiling code on the sourceforge server, so the c client is still born.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stepping away from the problem, it occurred to me that when the web server runs a cgi script, its running as someone that isn't in the openknights group (in the UNIX sense). So, this Perl script also wouldn't work without compromising the security of our web server space.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, CGI IRC is now working because I am serving it from my machine. I put a link to both the java applet and cgi irc client on the front wiki page. Playing around with these solutions shows them to only work well with certain web browsers. If someone wants to do the experiments, a list of which browsers work well might be useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Malakh: The current version of the IRC client connects but is very frustrating to use, at least on Safari. The sidebar scroller controls work erratically, and your typed text doesn't automatically appear in the window. Plus the color selections can lead to weird results (and some people seem to object to this.)
Finally, its complaining that we are running an "unregistered copy". Does this mean they expect Money ?! for this less than stellar piece of coding? I would say that we should not directly link to this from the tiki-home page, at least until some of the bugs are worked out. (Or at least advertise that it is not Safari friendly).
I know I was the one that asked for this capability... and I appreciate the effort. But if this is what we can do, then its more a minus than a plus, in IMHO. I apologize.
Oh and a final note... *will* this actually get around the firewall issue? Since it runs client side and not server side? My intuition tells me that it actually doesn't get us around the problem that started us on this merry chase.
Ras,
I posted that java irc client. You're right, it may be no better than a stand alone client as far as firewalls go, so I removed that statement. I don't think we'll be able to do anything better unless we can control the IRC server (or even better the machine on which it runs).
I posted some other comments about this in the Admin blog. Its shareware, and thus the messages. It works best with IE and Netscape.
jazzdman
I put it on the front page, because AFAIK, the only one's who know about the tiki-wiki are active members, or those who search through the forums. I can try posting the other IRC client I found, but it is even more "crippled" and may not work any better with Safari.
Hmm,
Some more searching on the web reveals this :
cgiirc.sourceforge.net
From that website
"CGI:IRC is a Perl/CGI program that lets you access IRC from a web browser ...has many uses ... or to acces IRC when stuck behind a restrictive firewall"
I'll try this one, but again, where would you like me to put the link?
I would say that if this runs server side (as a cgi) then it could very well get past the firewall issue. If we can install that on the SF site (don't know what CGI abilities we are allowed) then give it a try. You can put the link on the home page for now, but I was thinking of having a special IRC page anyway to give info about where to go for IRC clients and help, etc. That would be the right place to put the link to our applet(?) anyway, in my opinion. Thanks for keeping looking.
Well, experimentation with cgiirc did not pan out. There are two available clients, one in perl and one in c. For some reason, the perl client craps out trying to create a directory while opening a socket for communication? If anyone wants to take a look at the Perl client (which isn't very well commented) , line 489 of nph-irc.cgi in
/home/groups/o/op/openknights/cgi-bin/cgiirc-0.5.3 is what is producing the error I am seeing.
There are no facilities (for good reason I imagine) for compiling code on the sourceforge server, so the c client is still born.
Stepping away from the problem, it occurred to me that when the web server runs a cgi script, its running as someone that isn't in the openknights group (in the UNIX sense). So, this Perl script also wouldn't work without compromising the security of our web server space.
What a pity... I guess this was too much to ask for given what we have to work with. Oh well.
OK, CGI IRC is now working because I am serving it from my machine. I put a link to both the java applet and cgi irc client on the front wiki page. Playing around with these solutions shows them to only work well with certain web browsers. If someone wants to do the experiments, a list of which browsers work well might be useful.