[Openais] can we export coropoll as a library?

[Carlos Maiolino]

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
> > > Openais at lists.linux-foundation.org
> > > https://lists.linux-foundation.org/mailman/listinfo/openais
> > 
> 

-- 
---

Best Regards

Carlos Eduardo Maiolino
Support engineer
Red Hat - Global Support Services