Differences between revisions 32 and 33
Revision 32 as of 2005-12-18 13:37:41
Size: 9595
Editor: TimoSirainen
Comment:
Revision 33 as of 2009-03-15 22:42:40
Size: 9589
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Remember to read [wiki:Comparison Comparison] page first to understand what Icecap actually even tries to be. I also updated the introduction to be better now. Maybe the comments will be of better quality now ;) Remember to read [[Comparison|Comparison]] page first to understand what Icecap actually even tries to be. I also updated the introduction to be better now. Maybe the comments will be of better quality now ;)
Line 56: Line 56:
 * The "replacing IRC by Irssi2 servers" idea was just something I had thought about vaguely. Nowadays I don't think Icecap protocol should even try server-to-server communications. Something else could be used for that. [wiki:Comparison Comparison] page talks now more about differences between Icecap and PSYC and others.  * The "replacing IRC by Irssi2 servers" idea was just something I had thought about vaguely. Nowadays I don't think Icecap protocol should even try server-to-server communications. Something else could be used for that. [[Comparison|Comparison]] page talks now more about differences between Icecap and PSYC and others.

Remember to read Comparison page first to understand what Icecap actually even tries to be. I also updated the introduction to be better now. Maybe the comments will be of better quality now ;)

New comments here

Older comments

#1 LOL. This is totally fucking worthless. I mean we all know irssi1 was overengineered (but that was a good thing) but this? What the fuck are you smoking? IMAP? Dovecot? separating server from client? Get real faggots. All attempts to integrate irc with IM shit failed, why waste time on this, how about fixing bugs in irssi1 instead?

  • irssi2 isn't really about integrating IRC with IM though. Maybe wait and see how it'll work. As for fixing bugs in irssi1, you're welcome to do it (I just don't care anymore, it works fine for my use). -tss

#2 It's not unix-way, sorry. To restore IRC session remotely you can use ssh+`GNU screen', for example. And it's not so good that ONE application do everything (100in1). I'd prefer ONE application that do IRC perfect, _another_ ONE for perfect Jabber client and so on. It's all about unix philosophy. My choose is irssi 1.

  • The unix way is to use one command/application for each function, if this function is to communicate over sevral protocols, then it should be a single program, i prefer to have one function for communication over internet over having sevral diffrent, and since there is no standard yet, i'd pack all diffrent methods into one program.
    • Oh. You prefer to type "internet ssl ftp ftp://host" and "internet irc irc://", "internet mail pop://...", where "internet" is all-in-one application? wow! It's a ""great"" idea. Imagine all-in-one application "X": browser+mailer+editor+IDE+database+compiler+audio player+video player+PIM tool+irc+whatever, and all above is just ONE application. And better to integrate that appliction to OS kernel. Cool? No, dammit! It's not unix way.

      • As long as irssi2 can be build with only IRC support and all other "modules" disabled, it should be fine.
  • Actually irssi's IRC support is pretty outdated/bad. irssi2 already handles IRC core a lot better than irssi (eg. 005 events, event redirection), and it only gets better at handling IRC. I intend to use irssi2 only for IRCing, and it will be perfect for it. -tss
    • So.. better to improve/fix old-good irssi1, isn't it?
      • Go ahead if you want to :) I don't really.. -tss

        • I'm already fixed some bugs that annoy me in the past. Today I'm happy with current irssi1, even without 005 events.
    • Will that better IRC support be 'backported' to irssi1? Please? Pretty please? irssi1 is all I need, but it has some flaws.
  • ssh+screen is awful to use with slower internet connections, eg. GPRS. Also terminal interface makes some things more difficult, for example pasting text with tabs.. -tss
    • I think that irssi2 protocol over net + ssl/tls will be not faster than ssh (handshakes, e.t.c.) - I may be wrong. And there is -C option in my ssh (openssh), will it help you? Anyway, it's extreme case and after 1-2 years we all forget about GPRS connections at all. All above not a cause to invent new protocols/applications, IMHO.
      • irssi2 can already run over ssh. Problem isn't the bandwidth, but the latency. When I type text, it takes a second for each character to get visible. If the client is run on local computer there is no latency. -tss
        • I'm currently have 256 kbit/s connection, even at home. We are in the different worlds, I guess. Again: anyway, soon, that problem disppear - to that time irssi2 will be fully usable, but needless.
          • So try to download some cd images, do a apt-get upgrade and have your wife/husband/boy/girl/friend/whatever play some netgame at the same time and then come tell us there's no lag. I have 2MBits here, and ssh+screen is sucky to type in if I download anything.

            • I have the same problem, with download link fully saturated lags in anything are huge. But that's not irssi's problem, the only solution would be QoS on provider's end or limiting download speed to 60% or so...

              • It's not irssi's problem, but it can be fixed with client-server approach
          • Latency also happens, and is totally unavoidable no matter what you do, if you happen to be on a different continent from where your screen session is. Clients that interact with users always need to be able to run on the local box. That's why AJAX is getting so much press for web clients. It moves more of the application interaction into the browser where it belongs.
      • Besides I'd rather want to run my IRC client in graphical user interface, not inside a terminal. The problem is that none of the current GUI clients are usable if you want to be able to access scrollback. Some IRC bouncers support that, but they're pretty ugly kludges as well (and they don't give more than few of the last messages. It would be pretty slow to send last day or two of scrollback of all joined channels. irssi2 allows fetching partial scrollback as needed, plus searching it on server side for eg. /LAST command). -tss
        • What the logs for? + You can ctrl+a d' in the screen' and forget that you are running IRC client. And again we are in the different worlds. I _love_ console-based applications, console is the best thing to do text work (IRC is in fact the text work).

          • BTW. this comment made me think of integrating terminal to irssi2 clients (ie. terminal windows could be just like channel windows) and screen-alike feature to irssi2 server :) -tss

            • You could call it crash. You know, cras + sh...
            • why not do it the other way around: make irssi put seperate windows in seperate screen windows, like epic4 can.
              • Because that doesn't solve the latency issues..

* I agree with the NO ALL-IN-ONE apps. I mean if you want to have IM in an irc client use bitlbee and improve on that as well as irssi1. Guess I'll stick with irssi prime for a looooonnnggg time... well atleast until weechat makes me a better offering.

#3 irssi2 sounds really good. Hopefully someone writes a client that remains irssi1 and works in commadline :)

  • Agreed. irssi-1 style client for irssi 2 would be sweet. But I don't really care; as long as someone makes a decent client, I'll be happy. (I can just as well handle a win32 GUI client as a console client)

#4 irssi1 + screen + ssh is a better alternative in this case: the server irssi is running on is not yours and it's firewalled so that you can only connect to port 22. Yes, you could pipe irssi2 port through an ssh pipe, but that's just inconvenient.

  • irssi2-over-ssh transport (which does NOT mean any kind of port forwarding!) already works and will stay as the primary transport for quite a long time. It's no more inconvenient than using SSH the normal way.

#5 Would it be possible to integrate GPG or other similar technology to ascertain that the man or woman you're talking to really is who he or she claims to be?

  • Sure, just like it's possible to implement for any other IRC client. Not necessarily useful as the other side would also need a compatible client. Perhaps you should try SILC.

#6 Why invent a completely new protocol? Why not simply use XMPP (the Jabber one)? It seems like a perfect fit for this sort of thing.

  • It's not a perfect fit since it lacks so many features. It could possibly be used as a base for the protocol, but after all the additions that are needed to fully support IRC, you might as well call it a new protocol again.

#7 I use irssi with fserve.pl to serve files. How would dcc/scripts look in irssi2?

  • Don't know. Maybe a bit similar, or at least not entirely different.

#8 Don't let the conservatives stop you - the separation of GUI and gateway is a logical step to take. PSYC was created with a similar point of view, although not as detailed and pragmatic as you. We shall take inspiration from that and improve our client interface abilities in PSYC, actually we would love people as competent as you to take part in such work rather than create new technologies with a similar intent. We have read through these pages and added thoughts from our point of view at http://about.psyc.pages.de/Irssi2 - but what has surprised us the most is how you can expect to replace IRC by Irssi2 servers - the challenges of routing and multicasting aren't easy to solve. IRC has done so in a rather simple way. Jabber hasn't solved them at all and is now facing serious scalability problems. PSYC has focused on these things since the very early beginnings and we have our technology available for installation today, we even have ebuilds since a few days ago (ha ha). So maybe we should find a way to agree on protocol and requirements and do a better thing together...?

  • The "replacing IRC by Irssi2 servers" idea was just something I had thought about vaguely. Nowadays I don't think Icecap protocol should even try server-to-server communications. Something else could be used for that. Comparison page talks now more about differences between Icecap and PSYC and others.

#9 How is the separation of GUI and gateway a logical step? Will I be able to install irssi2 as an irssi1 gui-only (gui as in the console interface) application? I hope this will result in a fork.

  • Yes, you will be able to run irssi2 client without having to install server part separately, if you don't want to. Result in a fork of what? irssi2 isn't based on irssi, so it already is kind of a fork.

Comments (last edited 2009-03-15 22:42:40 by localhost)