On Wed, Mar 17, 2010 at 10:03:49AM -0700, Steven Dake wrote: > On Tue, 2010-03-16 at 11:50 -0300, Carlos Maiolino wrote: > > On Tue, Mar 16, 2010 at 01:30:19PM +0000, Christine Caulfield wrote: > > > 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 > > > > > > > that's a good idea. Let me know if I can help maintaining the tree, I have > > some free time available to do that. > > > > see ya.. > > > > Carlos, > I'm certain Angus could use any help you could provide.
Of course Steve. Angus, please let me know if you need any help... cmaiolino on #linux-cluster channel... > > Regards > -steve > > > > > > Chrissie > > > _______________________________________________ > > > Openais mailing list > > > [email protected] > > > https://lists.linux-foundation.org/mailman/listinfo/openais > > > -- --- Best Regards Carlos Eduardo Maiolino Support engineer Red Hat - Global Support Services _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
