Research and Development 1/^Archief/2009-2010/14/Contact tussen de QXmpp-developers en ons

Deze pagina is gemaakt om een overzicht te geven van contact tussen de developers van de QXmpp-developers en wij.

Eerste kennismaking

26 maart, van Sjors

Hi, developers of QXmpp,

We are a group of six people, working on a Google Wave server and client for a university
course project. We will use the C++ language with the Qt libraries. In the first phase of our
project, we found your library, therefore I'm sending this e-mail.

We will most likely be using your library a lot, if we can. We're currently looking into XMPP
and the exact specifics of the Google Wave protocol, including designing our own
client-server protocol. Since I understand your library is somewhat focused on Jabber/XMPP-IM,
we may be going to alter the code of your library here and there. Also, since half of our
project is building a server, we will also have to add code to your library to give it XMPP
server functionality.

Of course, we will gladly send back any changes we make (apart from that we have to,
since your project is LGPL licensed). Our own project will likely be BSD licensed, so I
understand we are allowed to link both dynamically and statically to your library.

I'm mostly sending this e-mail to let you know this, and to hear your opinion about this.
What do you think about using your library for the Wave protocol? Have you been thinking,
inside your project, about adding server functionality? Do you think it will be a
considerable amount of work[0], and do you have some hints before we start in two weeks?

Thanks a lot, also on behalf of my fellow project members,
Sjors Gielen

[0] considering that we know, and have some experience with how Qt and Qt's sockets work,
and have read or will read the XMPP RFC's, but have not actually used XMPP yet.

26 maart, van Jeremy Lainé

Hi Sjors,

Your project sounds like fun! Concerning the support for XMPP server functionality, I am not
convinced there will be a generic way of integrating this into QXmpp itself. However,
QXmpp does provide an interesting code base to start an XMPP server.

I have done this for one of our inhouse development, if you are interested you can check out
the following code:

git clone git://git.bolloretelecom.eu/xmpp-share-server.git

Look at the xmpp_server.h and xmpp_server.cpp files, they implements a minimalistic XMPP
server in under 500 lines of code. It's very basic, but in my experience it works. The biggest
missing feature is authentication, as I have not yet decided how to store credentials. However
it's just a question of plugging in the necessary code where I put a FIXME. You do get nice
things such as TLS with the existing code.

The code is currently under GPL, but if you are interested it could be relicensed to LGPL.

27 maart, van Manjeet Dahiya

Hello Sjors and Team,

It will be interesting to see a Google Wave application using QXmpp. I think Wave client is
built on top of the pub-sub extension of XMPP http://xmpp.org/extensions/xep-0060.html
(correct me if I'm wrong). Right now there is no native support pub-sub in QXmpp, can be
easily added though. After that one should not be bothered with XMPP and stuff. So, in my
opinion QXmpp is a perfect choice for Wave client. 

For server, you will have to investigate further, have a look at the the simple server code
suggested by Jeremy.

Cheers,
Manjeet Dahiya

Status-update

6 mei, van Sjors

Hello again, developers of QXmpp,

A while ago I e-mailed you because of our project. We are going to write a Google Wave
server using your library, QXmpp. We're now in the next phase, implementing the server
phase by phase.

At this moment we're trying to get a test application connected to other Wave providers.
This happens in a remote-host architecture (like client-server, but then the TCP client is
also server software) - that architecture seems to be, at least within the scope of XMPP,
unique to Google Wave. Within XMPP there is notion of an "XMPP server", obviously, and
also of optional "server-to-server" communication, without further defining the role or
hierarchy of a server.

Therefore, we want to add the notion of a standard XMPP server to QXmpp, then define
"Wave remote" or "Wave host" further inside our application. Does this sound right to you?
We will add a QXmppServer class, which will be similar to QXmppClient, because it also
connects to a server, and communicates with it in a similar way. Our current proposal is
to initially make QXmppServer derive from QXmppClient and then make minimal changes
to QXmppClient so the patches can be easily merged into your source base. Then, later
on, you or we will move QXmppClient to something like QXmppPeer, and both Client and
Server will derive from it.

What do you think about this approach? Do you have any comments or hints, or work
already done regarding this? Will you accept our patches, or help us improve their quality
if you think they lack on some points?

By the way: We will not start with implementing PubSub, until we have this working correctly.
Did you look into this yet, maybe design something or write some code? We will try to,
once it becomes relevant (which is soon), add it to QXmpp in a way that it will not be in the
way of current QXmpp features.

Thank you, awaiting your reply,
Sjors

11 mei, van Manjeet Dahiya

Hello Team,

All this sounds good to me. We will definitely accept the patches.

I hope you must have already checked the basic QXmpp based server which Jeremy had written.

Thanks,
Manjeet Dahiya

11 mei, van Sjors

Hi Manjeet,

We had forgotten about that server already! Thank you. We're checking it out again now.
There's an enormous amount of documentation missing in the Google Wave specifications,
like how server to server connections are actually implemented apart from XMPP Core;
at least I hope Jeremy's XMPP server will help us find out more by trying to connect to
other servers. We're also checking out other code.

We will keep you up to date. Thanks again!

Sjors

11 mei, van Sjors

> Hi Sjors,

Hello Jeremy,

> Your project sounds like fun! Concerning the support for XMPP server functionality,
> I am not convinced there will be a generic way of integrating this into QXmpp itself.
> However, QXmpp does provide an interesting code base to start an XMPP server.
>
> I have done this for one of our inhouse development, if you are interested you
> can check out the following code:
>
> git clone git://git.bolloretelecom.eu/xmpp-share-server.git

This repository seems to require qdjango, and has an empty directory for it, but I can't find
a good source base by Googling. Do you have it somewhere? Also, it seems to require a
CMakeLists.txt file for QXmpp, which QXmpp itself does not have (it uses qmake). Could
you send me your file?

> The code is currently under GPL, but if you are interested it could be relicensed to LGPL.

We're going to look how far we get like this, and will not publish any code at this stage.
If we are going to publish code, and we need it under LGPL, I'll tell you what code specifically
so you can relicense it. :)

Thank you,
Sjors

12 mei, van Jeremy

Hi Sjors,

> This repository seems to require qdjango, and has an empty directory for
> it, but I can't find a good source base by Googling. Do you have it
> somewhere? Also, it seems to require a CMakeLists.txt file for QXmpp,
> which QXmpp itself does not have (it uses qmake). Could you send me your
> file?

Just do:

git submodule update --init

.. then rebuild and it should be fine.

> > The code is currently under GPL, but if you are interested it could be
> > relicensed to LGPL.

> We're going to look how far we get like this, and will not publish any
> code at this stage. If we are going to publish code, and we need it
> under LGPL, I'll tell you what code specifically so you can relicense
> it. :)

I'll discuss this internally, we could possible relicense under LGPL.

Concerning your effort to introduce a generic QXmppServer class, I have serious doubts as to
whether this would really work. The main problem I can see is that unlike the client side,
whose state can just be stored in memory, a server is going to need some sort of persistence
(typically a database) to store things suchs as rosters, user credentials, etc..

In the xmpp-share-server implementation, I use an sqlite database which I access via "qdjango",
as simple Qt-based Object Relational Mapper I am working on.

12 mei, van Sjors

Hi Jeremy,

In our current design, the final QXmppServer will probably simply emit a signal when, for
example, user credentials need to be checked. Then the actual server implementation will
provide its own way for permanent storage, whether it does it against sqlite, pam, kerberos
or whatever. I think an implementation of XMPP-server and its extensions would fit in the library,
provided that it's usable for many purposes and not just ours. Of course, we will do our best
to keep the right code at the right place, in the library or in our own application.

We're committed to give the patches a fine quality, even for first functionality patches. We're
still experimenting at this moment, however; we're going to wrap up our work in about a week,
probably, and we'll start to build more stable implementations then. I expect to be able to send
some useful patches your way in about two week's time. I'll probably make use of some of your
code as a reference, and if you are able to change the license to LGPL maybe copy some of it;
in return, I'll try to update you on what functionality of your server is then in QXmpp and how
you can patch your server to make use of what's in the library. 

Thank you,
Sjors

First patch to QXmpp

18 mei, van Sjors

Hello, Manjeet and Jeremy,

I hereby would like to send you our first patch to QXmpp. It only adds a few new source and
header files, and added functionality is not great, but at least the added functionality provides
a solid base for the rest of our patches. The patch applies cleanly to your newest SVN repository
at this time, revision 288.

I will explain shortly what this patch adds. The base class to create a listening server is the new
QXmppServer. It is a QTcpServer which listens on one port only. Once clients connect to it, it will
add them to a list of "unknown clients" and create a QXmlStreamReader for them. Using this
QXmpStreamReader, the class will attempt to recognise what kind of client is connecting. Most
likely, it will create a QXmppServerConnection if the other side started an XML stream with
xmlns="jabber:server", or it will create a QXmppClientServer if the other side started an XML
stream with xmlns="jabber:client". Other xmlns combinations or invalid stream openings will
close the stream with a stream error.

There is one exception to this last sentence: the class, if an XML error occurs, will attempt to
recognise if the client is speaking the wrong protocol. For example, it will currently recognise
whether an HTTP or IRC client is connecting, and if so, return the appropriate error for that
protocol and close the connection. This is an added feature which I thought was nice and easy
to implement.

QXmppServer allows setting policy like "will not accept clients" or "will not accept servers", in
which case if a client or server connects, it will be rejected with an error.

Currently, QXmppClientServer and QXmppServerConnection don't do anything when a connection
arrives. Even worse: they crash, because the connect() fails which hits an assertion. However,
in order to keep our branches close, I would like to propose you apply this patch even though
its added functionality is small - all other classes still work as they should.

If you have anything to say about these patches, please do. We have tried to pay attention to
your coding style.

I expect followup patches to come soon. For example, we intend to first move client-to-server
functionality from QXmppStream to QXmppClient and make QXmppStream a more generic class
used by all three connection classes.

Thank you,
Sjors

22 mei, van Sjors

Hello Jeremy and Manjeet,

Our second patch to QXmpp is almost ready. It adds an actual implementation for the server
stream, for both clients and servers. It will be able to set up TLS encrypted streams to connecting
clients and servers, and servers we connect to. Also it will support SASL for clients that want to
authenticate. Maybe dialback will be supported too, depending on how well stuff is going.

I wanted to ask you how the first patch is doing. Have you looked at it yet? I think it would be
best to have the first patch checked and committed by the time the second patch arrives. It will
make it much easier for you to check the second patch if you know how the first one works.

Thank you,
Sjors