On 16/03/10 07:55, Steven Dake wrote: > On Tue, 2010-03-16 at 18:53 +1100, Angus Salkeld wrote: >> On Tue, 2010-03-16 at 00:34 -0700, Steven Dake wrote: >>> On Tue, 2010-03-16 at 18:30 +1100, Angus Salkeld wrote: >>>> On Tue, 2010-03-16 at 00:14 -0700, Steven Dake wrote: >>>>> On Tue, 2010-03-16 at 17:47 +1100, Angus Salkeld wrote: >>>>>> Hi >>>>>> >>>>>> I found this a handy library whilst writing the cpg_test_agent >>>>>> for the test harness. Others might find it useful too. >>>>>> We currently have quite a few exposed (generic) libraries >>>>>> perhaps this could be one of them (logsys, ipc/s, etc ...). >>>>>> >>>>> >>>>> coropoll is exported currently via a header file, although I am not >>>> sure >>>>> it is packaged as a DSO. I had hoped people would start to use the >>>>> non-cluster APIs available in Corosync for their own client/server >>>>> applications, but as a developer when I think Corosync I think >>>> "cluster >>>>> software". This thought pattern may be a general condition of the >>>> other >>>>> client/server-ish apis in Corosync. It may be that providing those >>>>> reusable components is outside the mission and general audience of >>>> the >>>>> Corosync community. >>>>> >>>> It might be more useful to remove these more general parts into a >>>> separate library like many other projects have done. It will >>>> help to harden the library and focus corosync on it's prime >>>> mission (clustering). >>>> >>>> -Angus >>> >>> They already are separate libraries (except coropoll). The big things >>> missing are docs, examples, test cases, etc. ATM I'd rather spend my >>> efforts on fixing up the documentation for corosync, providing test >>> cases there, and examples. >> >> Maybe I was not clear, move these libraries into a separate project. >> >> This will help in people adopting them. At the moment you have to >> install corosync if you want to use some cool client/server libraries. >> Unless you are using corosync this really does not make sense. >> >> Also this could let someone else worry about the examples, test cases, >> docs for the library :) >> > > interesting idea, volunteering to maintain it? >
I think that's a good idea. there are a lot of programs with their own socket polling code (I must have written it 4 or 5 times myself!), so a well-tested library that does all the right things would be a boon I think. Not that I necessarily have the time to maintain it :S Chrissie _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
