Smuxi - IRC in a modern environment
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 97 | |
Author | ||
License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/45751 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FOSDEM 201024 / 97
1
2
4
5
6
8
14
15
16
17
23
29
38
41
42
44
46
47
48
50
53
54
62
63
64
65
66
71
74
75
77
78
79
80
82
84
85
94
00:00
TwitterProof theoryProgrammer (hardware)Projective planeClient (computing)MereologyCommunications protocolSoftware frameworkGame controllerMessage passingWeb 2.0View (database)TouchscreenPresentation of a groupDebuggerProgramming languageProcess (computing)Combinational logicCore dumpFormal languageFörderverein International Co-Operative StudiesSpacetimeEndliche ModelltheorieEnvelope (mathematics)Product (business)Cross-platformWindowRegular graphComputer programmingAreaMultiplication signFront and back endsServer (computing)SoftwareDifferent (Kate Ryan album)Arithmetic meanElectronic mailing listInstallation artSoftware developerLecture/Conference
06:52
Software developerINTEGRALMessage passingClient (computing)Hacker (term)DebuggerFinite differenceHash functionServer (computing)TwitterProjective planeGraph coloringCommunications protocolFinite-state machineElectronic mailing listTelecommunicationPlug-in (computing)Event horizonSoftware frameworkJava appletLoginRevision controlLink (knot theory)PlanningArithmetic meanRegular graphPhysical systemSoftwareConnectivity (graph theory)NeuroinformatikComputing platformIP addressGoodness of fitTap (transformer)System callLaptopReal numberPoint (geometry)Right angleHecke operatorFrame problemEndliche ModelltheorieMaxima and minimaPower (physics)Data loggerMoment (mathematics)Ocean currentStandard deviationComputer architectureInterface (computing)Differenz <Mathematik>Cross-platformLine (geometry)DatabaseBuffer solutionLecture/Conference
13:31
Server (computing)Lecture/ConferenceComputer animationPanel painting
14:06
Server (computing)Message passingWeb 2.0Multiplication signComputer animation
14:42
Reading (process)WritingTable
15:09
TwitterServer (computing)Communications protocolWeb pageJava appletMessage passingClient (computing)Proof theoryPrice indexLibrary (computing)WritingProcess (computing)ImplementationFocus (optics)Computer animation
Transcript: English(auto-generated)
00:32
Here we go. Attention, attention. Hello, I'm Mirko Bauer. I'm a devon developer
00:44
and one of my pet projects of the SmartCRC client which I'm working on my spare time in Australia. My spare time of the alien that is. And I want to introduce smartly today whom I have been working on the past few years
01:03
and I haven't. So, what is SmartCRC? SmartCRC is a user for the ISC client
01:23
It's cross platform, that means it runs on Linux FreeBSD also, Windows Mac OS X is also planned, but there's no installing yet, though there's one SmartCRC developer using it already on Mac OS X, but
01:43
there's no nice installer yet, that's coming. Right now SmartCRC has the GNOME frontend as primarily frontend other frontends are also planned, but I'm focusing on the GNOME frontend for now, because I want one
02:03
usable and finished frontend instead of having many frontends and all are unusable. SmartCRC is based on the client server model this makes it very special compared to other ISC clients
02:22
You could say or compare it to the IR SSC plus screen plus it's a SSC combination, but like I said before, it's GNOME based or GNOME focused, not text
02:40
like ISC is and at its core, Maxi is basically a mass-exchange framework, it doesn't care about protocols it doesn't care about views it's about messaging
03:01
the engine behind SmartCRC is rich that means all the message processing all the protocol handling, whatever is happening on the engine side, and the frontend that connects
03:20
to that engine and displays the data from the engine is lean that means the frontends are not many features are permitted, only the features that are needed for the presentation, for the view of the engine features, and as I already said
03:45
it's protocol neutral, because it's a messaging framework basically, that means it can handle any protocols that are message oriented message based, right now, I implemented
04:01
ISC support, and also Twitter, I finished the Twitter support some weeks ago, and it was more kind of fun project, I had the idea why the web frontend of Twitter is not that nice
04:21
can I use Twitter from SmartCRC directly and in two days I had the Twitter support and that was kind of proof of concept that the messaging framework, the protocol neutral part is really working, because I could adopt it very quickly
04:41
to a completely different protocol this leads us to why start the SmartCRC project for what reason, I mean, we have so many ISC clients out there, I can't list them all, they are just too much, every programmer
05:03
on this planet has probably written already an ISC client everyone, but that doesn't mean they are good so, I wrote Smuxy I tried different ISC clients say 5 to 10 or something
05:21
well, basically, I tried all the clients I could find on APT but, or with APT, and I couldn't really get used to any of those so I sticked with IRSSI and yeah, used it for a while, a few years
05:41
but by then I thought, well, some things are not the way I would like, I prefer to have it, so I went with Smuxy for example you have to use
06:01
Perl or C or other languages I don't like for extending IRSSI I prefer C Sharp for example as programming language, that was also the reason why I decided to write Smuxy, at that time there was no other ISC client written in
06:22
C Sharp, also most clients, yeah, they are written by programmers like every programmer, but somehow when it comes to ISC, programmers believe that software should be complicated and difficult to use I don't know why, but that's my impression when I see
06:43
a regular ISC client and yeah, like I said, IRSSI plus screen great solution, but no GUI, that's which I didn't like it didn't integrate at all into my desktop experience
07:03
which is, you know, and yeah, well of course hacking is fun, so I wrote Smuxy, some special features or goals of the Smuxy client
07:20
are the following, first it's cross platform, that's not by accident that was a goal, I want an ISC client that runs on different platforms, so users are not limited to pick one platform, they can choose the platform they prefer, or even switch between platforms
07:40
say at work you have to use a different operating system than at home or whatever also the major feature of Smuxy is that architecture, that the engine component can run on a different computer than the front end
08:00
the front end then can connect to that running engine inside the Smuxy server over the network but this doesn't mean I said simple clients, Smuxy can be used as a regular standalone client you can also start Smuxy and it connects you to
08:21
ISC and you are done with just using it, you are an ISC, that's simple so it doesn't have to be the client server model, but it can be yeah, Smuxy is a multi-protocol with Twitter finally, from the beginning
08:41
Smuxy wasn't ISC centric, but ISC was the most important protocol I needed for my daily communication with other hackers on my projects and also at work I added Twitter support because I am also using that instead of usual blogging, Smuxy has a
09:01
configurable interface, that means you can set up where the topic is where the tabs go, where the user list is, or you don't want the user list and all that, and also a very nice feature which I like is not seen in any other client, the unique nick colors that means Smuxy is picking a nick color
09:24
based on a hash from the nickname means you get a color, say pink for direct hex, and regardless where he is regardless of which channel, or even which protocol he's called direct hex, so he's pink
09:45
well, it makes it easier to recognize people by color at least for me, than by cryptical nicknames so, that's a nice feature I like so, what's pointless, Smuxy? The development is very active
10:02
most lately, different new developers joined the project one of them is working on Identica support because right now really Twitter is working not Identica, I write Identica has a Twitter-compatible RP but it's not supported yet, we still
10:22
tend to get that, also planned is message buffers, that means, say you have to close or kill your Smuxy server it means currently you lose your old messages but that's the usual problem with IRC clients
10:41
there's no consensus, anything, so what Smuxy is going to do next, is it will store those messages in a lightweight database, say SQLite, and if you restart the Smuxy server, the old messages will be reloaded into the buffers and you're not losing any messages, and you can
11:02
go back in history of all discussions and everything, there's also Sitegeist integration planned, I'm in contact with one of the developers for Sitegeist integration I don't know if you know Sitegeist, it's an activity
11:21
tracker, basically, and Smuxy will send in the future events to Sitegeist, so tracks activity on it, and what's also planned is a plugin framework using monadins, currently Smuxy has
11:42
no standardized plugin system, it uses a handcrafted, self-written plugin system for the multi-protocol support, but it's it has no public IP yet, which plugins officially can use, so it could break with a
12:01
really powerful link. In 0.8, I'm planning also to add a login framework, that's an important feature that's currently missing on Smuxy, it means it doesn't write any log files, so if you want to track or
12:21
re-read all discussions, currently there are no logs for that I know every client does that, Smux is not yet but up to today, there was no real demand for such features, so I don't know how much people are really needing it, anyhow, I will
12:41
implement it, because the less they need, I can see it and one version after that, I plan to add Java support also known as XMPP, the protocol at that point, Smuxy will become true multi-protocol, which is
13:01
currently also multi-protocol, but Twitter is not that feature rich, so that was quite simple compared to that so, after all this talking, I will try to get Smuxy running, I have to rely on the Wi-Fi and on the laptop, which is not mine, so I can't
13:24
make any promises I will just try, let's see how this works
13:54
so Smuxy is now connecting to the Smuxy server
14:09
so what I just did, I think you haven't seen it, I started Smuxy and asked where I want to connect to and I connected to the Smuxy server
14:20
I started in advance, which is running on the server the private server, which I have updated as you can see, they are all messages, these are old messages you can see the timestamp, it says 12 57
14:47
for example channel, let's go to the fossil channel I don't know if some of you have ISC running and are on the fossil channel, maybe you could write something someone on ISC right now?
15:03
again? there we go, that worked so it's live server running, it's not just a fake or something this is a live ISC session, and you can also see the Twitter support, and I will also take a quick
15:22
tweet, it's as simple as writing ISC message am I in it? I have to try, I'm not sure where the focus is
15:41
and now to send that to the Twitter server, and if you're on Twitter you should see that message on my Twitter page and yeah, let's now set the Twitter
16:01
how much time? we are already out of time, so 3-5 minutes so, any questions about this Maxi ISC client?
16:22
what Java library are you going to use for the implementation? Java library? I haven't decided yet, I tried different libraries, there's a proof of concept implementation of the Java support already also for the OSCAP protocol, say ICQ
16:41
and AIM, but there's no high priority on those, for the Java one I tried 2 or 3, and I haven't decided yet, I'm still open which Java library I will actually use any other questions?