Re: Transponder, a native messaging client
 

Are you sure that using swiften is a good idea?
1. It does not support simultaneous connections to several accounts.
Actually there was a question about that in swift mailing list and the answer was that: "Noted, thanks - it’s on the list and Daniel (one of our GSoC students) is looking at this over the summer." However the summer was the 2015 one... :D
2. It does not support XEP-0313: Message Archive Management. Can't imagine a multiuser chat where you see only those messages when you are present...

The best one is probably Conversations (android) and in the Linux desktop area Gajim (pygtk). Also Psi (qt5) says that XEP-0313 will be supported in version 2.0 (currently 1.3).

Re: Transponder, a native messaging client
 

Are you sure that swiften 4.0 (beta) doesn't support MAM? https://github.com/swift/swift/searc...utf8=%E2%9C%93

Re: Transponder, a native messaging client
 

Hmm, testing here Swift-4.0rc5.amd64.appimage and yes, message archive management is definitely not working.

Re: Transponder, a native messaging client
 

At work I'm one of the people who maintain & develop the Anaconda installer used by Fedora/RHEL/CentOS and other distributions. Anaconda has a sizeable codebase with a history getting back to 1999. but we don't really see any special Python related issues compared to if it was written in a different language and we can maintain it just fine.

It's certainly true that due to the awesome flexibility and dynamic nature of Python you don't get some of the benefits of static type checking and linting overall is hard to implement (though Pylint is already doing a pretty well & improving).

On the other hand I think the static type checking provided by strongly typed languages is overrated - it will find only the most trivial issues, while any real mistakes in the application logic will still show up at only at runtime. So you still need a comprehensive test suite either way & it seems to be less and less acceptable these days to develop nontrivial suftware without having a good test coverage and using CI.

Also in the Sailfish OS perspective - we have Python 3.4 (letst stable is 3.6), which compared to the ancient GCC version (4.8 I think ?) is substantially newer and should thus enable the use of resonably modern Python features, unlike with the default C/C++ compiler.

So I don't really see any real issues with using Python on this and I think it's a really good choice given the current state of the Sailfish OS toolchain.

Re: Transponder, a native messaging client
 

https://github.com/PyCQA/pylint/issues/1646
https://github.com/PyCQA/pylint/issues/1651
https://github.com/PyCQA/pylint/issues/1660
https://github.com/PyCQA/pylint/issues/1631
https://github.com/PyCQA/pylint/issues/1630

This was more than enough to drop obligatory pylint check at work. Especially the first issue.

Just as an integral of a small function over a big set, if you have a lot of small, trivial bugs, that could be easily caught - that's a big burden.

As for the static checking in C++, yes, this is often not enough. Enter Rust! :)

There's the updated GCC by rinigus.

Re: Transponder, a native messaging client
 

The discussing Python vs C++, every language has his pro and cons.

I already made some prototyping for the modules in Python which works fine. I'm also trying the implement the same thing in Qt C++ to check out which way is the best one.

Currently I'm stuck a little bit between the 2 languages since I'm considering to add 3rd party support (at least the basis to do that) and this has pro and cons for both languages.

Re: Transponder, a native messaging client
 

On 1)
I have not looked into the code about this until now. Someone will find this feature usefull, someone have only one account. It depends on the personal usage.

On 2)
MUC didn't need xep-0313 to work correctly in the client. The last recent messages of a group chat are stored on the server and will be send to clients which where offline. This is trivial implemented without the need of message archive management.

Re: Transponder, a native messaging client
 

In my opinion it is also not a thing python vs c++. When I start a project I have a look at the available frameworks and librarys which are available to handle the features I need. I think that should make the decision. It's very hard to write most things again from scratch.

Personally I would not start to work on such a framework. The linked discussion on gnome mailing list about telpathy says all about this approach.

But hey, this is open source. Everyone who has a need is free to implement things that make his life easier. I wish you all success with Transponder!

Re: Transponder, a native messaging client
 

schorsch, still, I think that we'll need to come around MAM sooner or later, anyway. I often receive some links on the phone but want to view than on the computer.

So this will wind up as writing PRs against swiften. Not saying that it's not the best solution here, I don't know the alternatives.

/edit: from the Conversations channel:

Re: Transponder, a native messaging client
 

Yes, to some extent it works. But my experience shows that this is not very reliable. Not to say, that when server is restarted, then everything is lost. Sometimes my own text is missing at all etc... Maybe it can be configured to your need when you have a full control to the server yourself...