Moving to GitHub!

[guenter]

This week we will move the source code repositories for 1.4 and 1.5 from SourceForge SVN to GitHub. Plan is to have two separate repositories, one "legacy" for ongoing 1.4.x maintenance, and one "main" based on current trunk. The 1.5.0 release will be a branch of main. I have already created a pocoproject organization on GitHub, with Alex and me as owners. Repository URIs will be published as soon as we've moved the code.
For now we'll continue to use the SourceForge tracker and file release system, but we may eventually move to the GitHub issue tracker.
As of today, all SVN repositories on SourceForge are read only.

[wisesteve]

Will you still be wanting patches by mail, or should I wait a few days and send a github pull request instead?

[alex]

I'd say for now, best to file them in the SourceForge. Once we get comfortable with GitHub environment perhaps we could move the issue tracker as well.

[AjK]

Hi Alex (et al)

I've just been over to Github ( https://github.com/pocoproject ) and can't see any repos yet. Is this still work in progress?

And, since this is my first post I better introduce myself.

I'm looking to do some refactoring of Pocos use of epoll in the socket layer, specifically, avoid the complete rebuilding of the event data arrays on each select() call.

Once I have done that I'll then look at adding kqueue support of *BSD and OSX platforms. Finally, if I get time, looking at then the Windows IOCP (however, I'm not really too concerned at this point about that latter one, IOCP, since I wouldn't ever use Windows for a server expected to maintain 1000s of connections but would like to do it "for completeness").

About me, I've been writing code (C/C++) since the 1980s and I have a lot of experience with kqueue, epoll and libevent/libev.

And, all being well, I hope to become a regular contributor to Poco since I've come to enjoy it so much

regards,
--Andy

[alex]

Andy,

Günter is working on GitHub, I'm sure he has something else going on and could not get to it yet (I'm waiting for it, too). At this time, it is safe to grab the 1.5.0 branch from old SF SVN subversion and work on top of that.

Async IO will be very welcome, we've had people asking for it many many times, most recent discussion was on the poco-develop mailing list. I'm very busy with other things but, if you are really serious, let me know if you need any help or advice - I'll help the best I can.

Alex

[AjK]

Alex,

Thanks for the links and advice. I've had a read and am going to plan out how to go about doing the work.

Although I have years experience with epoll/kqueue et al, I've only been working with Poco for a few months (and not in it's Net code).

So my first point to to grok the current code first and then workout the requirements I want to get to based on where we are now.

I'll let you know how I get on.

regards,
--Andy

[alex]

While you're at it, you may also take a look at the coroutines in boost. They go nicely with async io. Now, if we could only find a way to reconcile thread, async io and coroutines into the same model, life would be good.

[guenter]

The POCO repository is now available on GitHub: https://github.com/pocoproject/poco.git

We'll use the branching model described in http://nvie.com/posts/a-successful-git-branching-model/

Happy hacking!

[zeeshan]

I'm looking to do some refactoring of Pocos use of epoll in the socket layer, specifically, avoid the complete rebuilding of the event data arrays on each select() call.

Once I have done that I'll then look at adding kqueue support of *BSD and OSX platforms. Finally, if I get time, looking at then the Windows IOCP (however, I'm not really too concerned at this point about that latter one.
http://pocoproject.org

[alex]

I'm looking to do some refactoring of Pocos use of epoll in the socket layer, specifically, avoid the complete rebuilding of the event data arrays on each select() call.
http://pocoproject.org

Off topic, please move discussion to wishlist.