[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libssh] [PATCH 1/2] Add a generic way to handle sockets asynchronously.
[Thread Prev] | [Thread Next]
- Subject: Re: [Libssh] [PATCH 1/2] Add a generic way to handle sockets asynchronously.
- From: <mail@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Fri, 03 Jul 2009 12:40:09 +0200
- To: <libssh@xxxxxxxxxx>
On Fri, 03 Jul 2009 10:15:18 +0200, Aleksandar Kanchev <aleksandar.kanchev@xxxxxxxxxxxxxx> wrote: > Why is glib so scary? :) > glib changes way to often. I've thought about using glib for my file synchronizer so I've talked to a lot of colleagues. They all said that you have to often adapt to the new api. You run often into a problem and then have to wait for a new version to get it fixed. If I meat my friends they often blame about the new glib version. One of them is a opensync developer. > The pros of using glib is that it offers some nice things, like lists, > arrays, main loop, io channels and multi-threaded support. Stuffs that > are needed by libssh and stuff you don't have to worry if they are > implemented right, since that's the idea of a library. People are using > libssh for the very same reason. I have list functions, rbtree functions and more available and they are well tested. I care about resources and fast algorithms I'm not sure if glib developers do it the same way as I do. > I hope that you're also interested in expanding libssh to support more > and more features. If that's true, then using external libraries will > definitively help. I'm not saying that every new library should be a > hard dependency, but since glib is a core library, then it should be. It is a bad core library. They break to often the API and the ABI. > You could of course dismiss new libraries and implement the stuff > yourself but really, what's the point of reinventing the wheel? Why not > concentrate in expanding the ssh functionality instead? Are really that > many (windows) users that require this effort? Can't those users > continue using the "old" libssh? Wouldn't there be even more users if > the library "plays well"? I don't want to maintain two libssh libraries. It is enough to maintain a stable and a development branch. It would be possible to integrate libssh in the glib mainloop and create a file in libssh with a compile option to enable that mode. Just my 2 cents... -- andreas
Re: [Libssh] [PATCH 1/2] Add a generic way to handle sockets asynchronously. | Aris Adamantiadis <aris@xxxxxxxxxxxx> |
Re: [Libssh] [PATCH 1/2] Add a generic way to handle sockets asynchronously. | Aleksandar Kanchev <aleksandar.kanchev@xxxxxxxxxxxxxx> |