Future of teamwork plugin

[Andreas Pakulat]

On 04.07.07 00:38:30, David Nolden wrote:
> Am Dienstag, 3. Juli 2007 22:43:02 schrieb Andreas Pakulat:
> > stable != not crashing, but I think you're aware of that.
> Of course I know that. That's why I added the "not crashing".

Ok, good. Also earlier I asked about tests, what I meant were unittests
so if somebody wants to rewrite the network code he can make sure it
still works as expected.

> > It is dead code and I think one of the issues we wanted to avoid in
> > KDevelop4 is carrying dead code around. What is so bad about moving the
> > plugin to a (quite popular) place in playground?
> 
> Dead code is relative..

Oops, forgot to insert the "currently" there.

> just because noone works on something for half a year doesn't mean
> it's dead, else kdevelop-3.4 would be 90% dead since years.

Well, it is. There are 13 lanuage plugins of which 2 work well
(cpp+ruby) one is maintained somewhat (ada) and the rest just lingers
around. Same thing about some things in parts/ and one or two of the
vcs'.

> > Its not in a working state right now, except on your and my system. That
> > is it doesn't compile against boost 1.33.1. Its also in a non-working
> > state on at least 1 platform other than linux and yes IMHO that counts
> > wether KDE4/win32 happens for 4.0 or for 4.1.
> 
> It does compile with boost 1.33.1, that's what I developed it with. You're 
> maybe referring to a problem with the ubuntu feisty boost-packages, they are 
> broken(dapper worked, and gutsy works too, that's why I had to upgrade).

I have no idea what runs on dashboard, all I know is that its boost
1.33.1 there and IIRC Kris also had problems. Not sure what he runs
though. Kris?

> It also doesn't compile with amd64 because of a bug in boost(cannot serialize 
> 64-bit integers on 64-bit systems). But that can be workarounded easily. 

So you have that workaround in teamwork? Else quite some people won't be
able to use teamwork because one of its dependecies has
platform-independence-issues.

> Stays windows..

Vladimir told me on IRC that its not that much of a problem. I have to
admit that I didn't yet try to compile boost, because CommonC++ took all
my win32-time. All I heard was that there was some effort to port it to
cmake (for which there must be a reason) and Ralf Habacker said on
kde-windows or in a private mail (too lazy to go mailhunting right now)
that its not easy to build or it produces extremely large libs.

> mathieu:
> > "the only future I can see for this plugin is a rewrite ... I don't know 
> about it but maybe also a redesign ... "
> 
> Rewrite, redesign? What exactly is wrong about the design? Imo, the design of 
> the networking-library is great, I'm proud of it. It is easy, multithreaded, 
> safe, powerful. I wouldn't do it different now, except that I'd use qt. 
> 
> Your statement shows that you haven't understood anything about the design.
> 
> That's probably my fault. I've created a imo good system, but probably missed 
> out documenting it enough for others to think the same about it. The whole 
> thing may be a little messy in some places, but mostly It's good in my 
> opinion. I've used advanced features of C++ to make the code cleaner and 
> safer.

Strange that you are the only one thinking the code is clean. I won't
comment about the safe-part, because I don't understand the code enough
to comment on that.

> It may need a little time to understand some of the things, but once you did, 
> you would see how cool it is. I do not have the feeling that anyone really 
> tried understanding the stuff and maybe even learn some new concepts, but 
> instead just start yelling as soon as they see something that does not look 
> like the usual kde/qt code.

Right, I didn't sit down for several hours studying under-documented
headers with tons of templates (which I'm still no expert in). And this
is exactly my point all the time: It takes much time to dive into this
design and understand it. Even STL is easier to understand when you just
need the basic usages.

And that would just be using it, not even changing the code, as in
maintaining it.

I'd like to add here that it already took me quite some time to fix the
include-headers in 3 of the files. That is moving the #include
<foobar.h> in a foobar.cpp to the top position. This caused compilation
problems and I needed to do some reordering in other files. Took me
quite more than just 10 minutes.

Andreas

-- 
Cheer Up!  Things are getting worse at a slower rate.