Re: [boost] asio projects (was: Boost and Google Summer of Code2007)
Ames Andreas wrote:
Do you have a estimate on a completity of this task? To be honest, I don't know; such an estimation would need to be part of the project itself. Nevertheless I would guess that it's feasible given that TAO has an explicit API to replace its own GIOP stack, see: www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf
Wow! I didn't know it has API. This simplifies student's time a lot and reduces "time to market". Funny thing is that a student will face ACE vs Boost battle ;-)
I don't know of a similar API in omniORB but at least it supports a 'pluggable transport framework', i.e. you can 'easily' replace the transport layer beneath GIOP (usually IIOP). How this extends to a GIOP replacement would need to be researched separately. FWIW, the CORBA spec explicitly mentions that protocols other than GIOP should be possible (within the abstract CORBA architecture). Another interesting project goal would be to create an API that allows writing compliant objects and/or clients without IDL support. CORBA has the Dynamic Invocation Interface (client side) and the Dynamic Skeleton API (server side). Maybe a student would be interested in trying to create a good generic interface to show off the power of generic programming compared to those more traditional approaches. cheers, aa
-- Alexander Nasonov
Brrrr, I pressed some key combination in a web interface and it sent my message when I was in the middle of editing the forth sentence. I resent the message but to incorrect address. It doesn't make sense to repost so late. In addition to what I wrote I was going to mention langbinding as a possible approach to API "that allows writing compliant objects and/or clients without IDL support". Alexander Nasonov wrote:
Ames Andreas wrote:
Do you have a estimate on a completity of this task? To be honest, I don't know; such an estimation would need to be part of the project itself. Nevertheless I would guess that it's feasible given that TAO has an explicit API to replace its own GIOP stack, see: www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf
Wow! I didn't know it has API. This simplifies student's time a lot and reduces "time to market". Funny thing is that a student will face ACE vs Boost battle ;-)
I don't know of a similar API in omniORB but at least it supports a 'pluggable transport framework', i.e. you can 'easily' replace the transport layer beneath GIOP (usually IIOP). How this extends to a GIOP replacement would need to be researched separately. FWIW, the CORBA spec explicitly mentions that protocols other than GIOP should be possible (within the abstract CORBA architecture). Another interesting project goal would be to create an API that allows writing compliant objects and/or clients without IDL support. CORBA has the Dynamic Invocation Interface (client side) and the Dynamic Skeleton API (server side). Maybe a student would be interested in trying to create a good generic interface to show off the power of generic programming compared to those more traditional approaches. cheers, aa
-- Alexander Nasonov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alexander Nasonov http://nasonov.blogspot.com Such men as he be never at heart`s ease whiles they behold a greater than themselves, and therefore are they very dangerous. -- William Shakespeare -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful. Is it worth my while submitting a proposal? This is something I'd very much like to do, especially as part of the SoC. Incidentally, it's a project which _could_ be 'extended' into implementing unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications. Regards, Darren
On 3/9/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful. Is it worth my while submitting a proposal? This is something I'd very much like to do, especially as part of the SoC.
Incidentally, it's a project which _could_ be 'extended' into implementing unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications.
What I would really like to see in asio is asynchronous FS IO (using Ovelapped IO on windows, posix aio where available and a thread pool everywhere else). There have been many requests for this functionality, but Christopher didn't get around to implement it yet. I think that such a project could be completed in a couple of months. May be the student could even find the time to add pipe support :). As soon as I find some time I'll add the proposal to the wiki. gpd
Giovanni Piero Deretta wrote:
On 3/9/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful. Is it worth my while submitting a proposal? This is something I'd very much like to do, especially as part of the SoC.
Incidentally, it's a project which _could_ be 'extended' into implementing unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications.
What I would really like to see in asio is asynchronous FS IO (using Ovelapped IO on windows, posix aio where available and a thread pool everywhere else). There have been many requests for this functionality, but Christopher didn't get around to implement it yet.
This sounds like an excellent project. Christopher has also graciously agreed to be a boost SoC mentor -- so there's a good chance such a project can get expert help.
I think that such a project could be completed in a couple of months. May be the student could even find the time to add pipe support :). As soon as I find some time I'll add the proposal to the wiki.
Please do -- the student proposal period isn't far off... Jeff
On 3/9/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Giovanni Piero Deretta wrote:
[...] What I would really like to see in asio is asynchronous FS IO (using Ovelapped IO on windows, posix aio where available and a thread pool everywhere else). There have been many requests for this functionality, but Christopher didn't get around to implement it yet.
This sounds like an excellent project. Christopher has also graciously agreed to be a boost SoC mentor -- so there's a good chance such a project can get expert help.
I think that such a project could be completed in a couple of months. May be the student could even find the time to add pipe support :). As soon as I find some time I'll add the proposal to the wiki.
Please do -- the student proposal period isn't far off...
Added to the wiki as "Asio Asynchronous FS Support". Link here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... gpd
On 3/9/07, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
[snipped]
What I would really like to see in asio is asynchronous FS IO (using Ovelapped IO on windows, posix aio where available and a thread pool everywhere else). There have been many requests for this functionality, but Christopher didn't get around to implement it yet.
I have something like that already. But not very well thoughout. On both posix aio and overlapped IO. The biggest problem is that opening a file is *very slow*, and must be done synchronously within a thread pool.
I think that such a project could be completed in a couple of months. May be the student could even find the time to add pipe support :). As soon as I find some time I'll add the proposal to the wiki.
I want to make a proposal for SoC in boost. But I was thinking about something else (a better bcp utility), I believe boost would benefit from better tools in this moment. Maybe I could apply for both, and boost chooses what (if any) is better for boost.
gpd
-- Felipe Magno de Almeida
On 3/9/07, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
On 3/9/07, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
[snipped]
What I would really like to see in asio is asynchronous FS IO (using Ovelapped IO on windows, posix aio where available and a thread pool everywhere else). There have been many requests for this functionality, but Christopher didn't get around to implement it yet.
I have something like that already. But not very well thoughout. On both posix aio and overlapped IO. The biggest problem is that opening a file is *very slow*, and must be done synchronously within a thread pool.
AFAIK there is no posix interface yet for async opens. Don't know about windows though. There is a Linux project to make *any* syscall asynchronous though. Anyways, probably asynchronous open support could be implemented later. Basic AIO would be a first good step.
I think that such a project could be completed in a couple of months. May be the student could even find the time to add pipe support :). As soon as I find some time I'll add the proposal to the wiki.
I want to make a proposal for SoC in boost. But I was thinking about something else (a better bcp utility), I believe boost would benefit from better tools in this moment. Maybe I could apply for both, and boost chooses what (if any) is better for boost.
Go for it! gpd
Felipe Magno de Almeida wrote:
I want to make a proposal for SoC in boost.
Great!
But I was thinking about something else (a better bcp utility), I believe boost would benefit from better tools in this moment. Maybe I could apply for both, and boost chooses what (if any) is better for boost.
It's legal to apply for more than one project. However, since competition is fierce it might be wise to put all your effort into making the one project you really want to work on great. Of course if someone else submits a similar proposal having a second project could be an advantage. You'll have to decide on how best to apply your time during the application period. Jeff
Darren Garvey wrote:
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful.
Yes, I think this would be a very useful library -- I have a homegrown one I've used in some personal apps. C++ developers want to program for the web as much as anyone else and the libs for C++ are, sadly, poor in comparison to other languages. Before focusing in on SCGI and FastCGI, what about support for plain old cgi request decoding and such? Would that be part of it?
Is it worth my while submitting a proposal? This is something I'd very much like to do, especially as part of the SoC.
My worry is that the scope might be too large for SoC though. In any case, there might be a reasonable scope that could be carved out -- let's discuss it more :-)
Incidentally, it's a project which _could_ be 'extended' into implementing unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications.
Is it really worth it? TCP sockets are pretty optimized by OS's at this point... Jef
On 3/9/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Darren Garvey wrote:
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful.
Yes, I think this would be a very useful library -- I have a homegrown one I've used in some personal apps. C++ developers want to program for the web as much as anyone else and the libs for C++ are, sadly, poor in comparison to other languages. Before focusing in on SCGI and FastCGI, what about support for plain old cgi request decoding and such? Would that be part of it?
Is it worth my while submitting a proposal? This is something I'd very much like to do, especially as part of the SoC.
My worry is that the scope might be too large for SoC though. In any case, there might be a reasonable scope that could be carved out -- let's discuss it more :-)
Incidentally, it's a project which _could_ be 'extended' into implementing unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications.
Is it really worth it? TCP sockets are pretty optimized by OS's at this point...
Yes, but usually UDS (and pipes that are often implemented on top of them) are still faster. Also sometimes you do not have a choice of the transport (think X-Windows over UDS) because it is dictated by some protocol spec. Also pipes support is useful if you want to participate in a shell pipeline. gpd
Giovanni Piero Deretta wrote:
On 3/9/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Yes, but usually UDS (and pipes that are often implemented on top of them) are still faster. Also sometimes you do not have a choice of the transport (think X-Windows over UDS) because it is dictated by some protocol spec.
Ok. But, I guess I see adding pipe support to asio as a completely different project than providing support for cgi/fastcgi, etc. AFAIK TCP sockets is the only transport for FastCGI.
Also pipes support is useful if you want to participate in a shell pipeline.
Sure, but again it seems like a different project... Jeff
On 09/03/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Darren Garvey wrote:
Maybe it's just me, but the apparent difficulty of the different soc ideas varies quite a bit. As it is, I'm unsure if a cgi library that works with SCGI and FastCGI - one based on boost and asio specifically - would be considered a reasonable project for the SoC? I don't think there is currently any such library for c++ and I for one would find it very useful.
Yes, I think this would be a very useful library -- I have a homegrown one I've used in some personal apps. C++ developers want to program for the web as much as anyone else and the libs for C++ are, sadly, poor in comparison to other languages. Before focusing in on SCGI and FastCGI, what about support for plain old cgi request decoding and such? Would that be part of it?
Of course. :) The idea would be to use a cgi::request object, which you could pass a 'service' object to: the service object deals with the protocol and then the resulting cgi-shaped request can be transparently accessed through the request object.
Is it worth my while submitting a proposal? This is something I'd very much
like to do, especially as part of the SoC.
My worry is that the scope might be too large for SoC though. In any case, there might be a reasonable scope that could be carved out -- let's discuss it more :-)
Well I've been having a go implementing the fastcgi protocol using asio and even though it's not finished, I believe given some dedicated time I could have it fully working. SCGI is supposed to be 'simple' - and seems to be - so that shouldn't be too big a deal to add: either way, that is something that could follow, I suppose? Then there's the docs of course. Forgoing any major oversight on my part, from what I understand so far, I think it is doable in 2-3 months.
Incidentally, it's a project which _could_ be 'extended' into implementing
unix domain sockets or pipes too as technically, these transport media should be supported by fastcgi applications.
Is it really worth it? TCP sockets are pretty optimized by OS's at this point...
It probably isn't, although I honestly don't know. Thankfully it won't really matter since servers should be able to run fastcgi apps via tcp anyway (apache and lighttpd do). Using UDS/pipes is purely an optimisation. Jef
Thanks for the reply, Darren
On 3/9/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:
Well I've been having a go implementing the fastcgi protocol using asio and even though it's not finished, I believe given some dedicated time I could have it fully working. SCGI is supposed to be 'simple' - and seems to be - so that shouldn't be too big a deal to add: either way, that is something that could follow, I suppose? Then there's the docs of course. Forgoing any
Which servers support SCGI but not FCGI?
On 09/03/07, Olaf van der Spek <olafvdspek@gmail.com> wrote:
Well I've been having a go implementing the fastcgi protocol using asio and even though it's not finished, I believe given some dedicated time I could have it fully working. SCGI is supposed to be 'simple' - and seems to be
On 3/9/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote: -
so that shouldn't be too big a deal to add: either way, that is something that could follow, I suppose? Then there's the docs of course. Forgoing any
Which servers support SCGI but not FCGI?
It shouldn't matter because there's no guaranteed way to differentiate a SCGI request from an FCGI one (although you can make a good guess, I suppose). Your point is noted though: SCGI should be included in any CGI/FCGI proposal.
On 3/9/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:
On 09/03/07, Olaf van der Spek <olafvdspek@gmail.com> wrote:
Well I've been having a go implementing the fastcgi protocol using asio and even though it's not finished, I believe given some dedicated time I could have it fully working. SCGI is supposed to be 'simple' - and seems to be
On 3/9/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote: -
so that shouldn't be too big a deal to add: either way, that is something that could follow, I suppose? Then there's the docs of course. Forgoing any
Which servers support SCGI but not FCGI?
It shouldn't matter because there's no guaranteed way to differentiate a SCGI request from an FCGI one (although you can make a good guess, I suppose). Your point is noted though: SCGI should be included in any CGI/FCGI proposal.
Actually, my point is more like the opposite. If all servers that support SCGI also support FCGI, there's no point in writing a client lib that supports SCGI because FCGI is faster (AFAIK) and will always be supported.
Actually, my point is more like the opposite. If all servers that support SCGI also support FCGI, there's no point in writing a client lib that supports SCGI because FCGI is faster (AFAIK) and will always be supported.
I misunderstood you, my mistake. Even though FCGI is inherently more efficient, given the simplicity in implementing an SCGI 'service' - in parallel to an FCGI and raw CGI one - and the current lack of complete FCGI support in apache, it still seems worthwhile. Plus, it's not beyond possibility that given small inputs and large outputs, on implementations that don't support multiplexing (apache, for instance, doesn't allow that), SCGI may just have an edge (a small one, admittedly). Essentially you're right, but if without SCGI, I may as well just implement an FCGI library that handles standard CGI, rather than a CGI library that handles FCGI, SCGI and any other potential protocols that map to CGI. If there's one thing Boost has taught me, it's that extensibility and flexibility are ace. :) Cheers, Darren
participants (6)
-
Alexander Nasonov -
Darren Garvey -
Felipe Magno de Almeida -
Giovanni Piero Deretta -
Jeff Garland -
Olaf van der Spek