It's been a week so I guess everyone who wanted to answer has.
Since Jon's mail seems to include the opinions from the other mails I
will reply to that.
I notice that no one has commented or objected to the ordering I used so
the highest priority would be to take care of the protocols with api and
daemon (Licq 2) being second. Although I realize that protocol
improvements/replacements will be easier if we sort out the API first.
Jon Keating wrote:
Licq 2 is planned to make up for all the deficiencies that are present
in Licq 1. And some of these deficiencies are in the base
architecture, which make a simple and slow merge over from Licq 1 a
bit difficult. Erik has created some of a code base, from what I
remember it is a good start. I am not advocating a start from scratch
approach, nor am I advocating a use the current code base. What I
would prefer to see is a start from the current base, and rewrite the
needed parts (Plugins, Signals, Events, Users). Yes, the needed parts
make up for a large part of Licq, but there are qutie a few parts that
don't, and time has gone into them to make them what they are now. At
times, this would make the code base unusuable, so that is why I'm not
advocating a slow approach as Anders proposed. But I don't think we
should throw away the code that is fine and still reusable.
I kept busy with Qt4-Gui when Licq 2 was last moving and I don't
remember much of the old discussions.
So can someone tell what the current status of Licq 2 is? How much is
done and what remains?
Also, is there a draft or design of how the new architecture and
interfaces should be? Or is the header files in the Licq 2 branch
updated to represent (and document) this?
Erik: If we get Licq 2 moving again, will you help with the work or have
you gotten other priorities nowadays.
1) Protocol support
I would to maintain the protocols, but I don't think I can commit that
much time to it in 2009. Perhaps it is time to look into libraries.
Just a few comments...
Licq has a few features that most implemenations don't have, such as
SSL connections. I still think SSL is a good way to get secure
communications without the user doing much work, so it is still
relevant. Also, there may be some features that got removed from the
official client, but still are supported on the server. We would have
to see what features an implementation can give us, and then see what
features we will lose. Also, we need to consider the future. If we
decide to use a library, how we do implement new features in the
protocol? We can write patches and submit them upstream, but what if
they don't get accepted? What if the library goes unmaintained? I
think we would need to branch from the library, to provide our own
code when necessary, plus we can sync up with the master branch to
upgrade to a newer version.
I've looked around a bit for library implementations of ICQ and MSN
protocol and I didn't find much. It seems most other IM clients have
there own implementations for these protocols. The main exception is
libpurple but there's not much documentation so I'm not sure how much it
does, but it looks like it contains more that just the protocol
implementation so if we use it we'll probably end up loosing more of our
daemon. However it seems libpurple compiles to make a separate sub
library for each protocol. If these have a standard interface, we could
get support for all those protocols with just one api. (If someone knows
more about libpurple, please correct me or fill in.)
We could of course make a library ourselves in the hope that other
(future) applications will also use it and help maintain it. However I
think for this to happen we will have to have a good implementation
that's up to date. Also if we're not careful we might end up with a
library interface that isn't usable for anything but Licq.
Another way would be to find another IM client to cooperate with and
make a library together. This way we could take the best parts from both
sides and then maintain it together. For MSN I guess it would mostly be
a matter of convincing another project to move their code to a library.
I don't have my hopes very high on this though since it would be asking
another group to do a lot of work that will (in the short term) mostly
be only for our benefit.
2) Daemon and plugin API
A part of the Licq 2 plan was to move the protocol code out of the
daemon. Licq was built for ICQ, so any new protocols (MSN) have been
hacked into it with a sloppy protocol plugin code (Yes, I take the
blame for that). Removing ICQ from the daemon will provide a bit more
of a challenge, as there are many places where it is closely tied
together. As I said before, this can be done, but I think it is best
to do it in a different SVN branch where we can break it and not
affect Licq 1. The actual plugin API for Licq 2 will be more simple,
so I think the actual extraction of the ICQ code should be for Licq 2
only. It will only provide more work in Licq 1, and then it will have
to be changed once again for Licq 2.
Yes, if Licq 2 is the way forward, it's not worth separating it in Licq 1.
3) GUI
Yes, the skins we have now are quite old and do show their age.
Especially looking at the skins provided for other applications. Even
if we do make other dialogs skinnable, if we don't have some artists
to create modern skins, it won't be very useful. So we should consider
this: What do we need to provide to the artists for making Licq
pretty?
Good point.
I was excited when Qt4-GUI was being worked on and even started on a
Kde4-Gui, but was so disappointed with KDE4, that I removed it and am
not interested in it anymore. Yes, this is just an opinion, but I felt
that KDE4 was such a downgrade due to the fact that I couldn't use my
XWindows in an efficient manner anymore.
I haven't been too impressed with Kde4 either, but it will probably win
users over time so I would like to get Kde4-gui working for those who
prefers it.
However, since Qt4 has a bit more desktop handling functions than Qt3 we
actually have most of the Kde3-gui features in the Qt4-Gui without
compiling it for Kde. What we're missing (that I know of) is spell
checking and integration with the kde address book. I would like to see
a non-kde spell checker it Qt4-Gui, I can live without the address book
sync and then the difference will just a matter of using kde widgets to
get the kde look and feel.
4) Tickets
I think 3 months without any response, or a way to reproduce it is
more than enough to mark it is "Invalid" or something.
Sounds like a reasonable time, at least for newer tickets. I'll go over
the list later and close the ones that are incomplete and has been
waiting for information but has gotten no answer for too long.
5) Other UIs
The old console plugin needs to be updated, probably even replaced entirely.
The console plugin has an IRC feeling to it with the command input at the
bottom. Maybe a more windowed approach would be better if redesigning.
The web plugin I haven't even looked at but I know it's had no commits for
at least two years so it probably could do with some freshening up as well.
Both are low priorites I think.
Yes, the other stuff is more important, but these are still worth doing
and I wanted to list them if anyone reads this and wants to contribute
but but feel that daemon, protocols or qt-gui is not their thing.
Well, first lets decide what we want to do before anyone starts
working on something.
Actually, since this is voluntary work, I don't think it's worth
deciding to do something unless someone will actually take the time to
do it.
Since it's been quiet the last months I mostly just wanted to check
who're still with us.
Can we get someone who would create skins? And then find out what we
need to offer to them to make it easier/better?
Yes, that sounds like the way to go. Does anyone know a potential skin
maker? If so then please let us know.
/Anders
