On Wed, 2010-03-17 at 21:00 +1100, Angus Salkeld wrote: > > > > interesting idea, volunteering to maintain it? > > > > > > > > > > Sure, I'de love to. > > > > > > > I had to give this some consideration. I am a big fan of "do one > thing > > do it well". Taken in this context, your arguments are pretty > > convincing... > > > > Could you go into more detail about structure, components, etc. I > have > > some ideas, but more interested in how you think this would be > > structured. > Well have a project that produces a number of libraries derived > directly from corosync. > > - list (header) > - tlist (header) > - hdb (header) > - timers (library) > - poll (library) > - objdb (library) > - ipc (client & server library) > - tsafe (library) > - logsys (library) > - lcr (library) > - wthread (library) > > - We need to decide to what extent this should be compatible with > glib (g_mainloop, g_timer, etc...). > - Also these will need to be as independent as possible so people can > use what they want without having to pull in everything. > - We also need to think how to handle logging & stats (currently > ipcs logs and produces stats). >
Definitely not taking objdb out of corosync. Much work needs to be done there and objdb is a huge dependency which any change could introduce significant ripple effects through the rest of the corosync codebase. The other components look reasonable. Other issues that need to be sorted out are -> namespace issues: ideally want a project name that allows us to prepend the apis such as poll_initialize with something else. I'm a big fan of two letter namespace identifiers. This would allow us to use a name such as XX_poll_initialize. I wish I could have done this with corosync (cs_cpg_initalize for example). I recommend starting out with this in mind. man page generation: I've been heavily investigating doxygen for use with corosync. It provides good gain for little pain. build system: autotools = win improvements in these implementations: I hope by splitting them out, we will continue to make improvements rather then push bits around to different locations. In general concept is sound minus the objdb thing. Robyn came up with the name "libquarterback" or "libqb" for short. If you like it, you can use it. Let me know off list and I'll set you up with a vm on corosync.org to set it up. We can target 2.x or 3.x for integration with libqb depending when the project becomes stable (builds, is packaged properly, hits community distro repos). I am not changing flatiron to adopt this library though. Regards -steve > > > > Also I hope you know what your getting into; maintaining a project > is a > > big personal investment. > > > Yes I know but also give me a chance to set direction to some extent > which will be fun. Obviously development will be driven from it's > main users so that should make it easy to guide it in the right > direction. > > -Angus > > > Thanks > > -steve > > > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
