On 09/14/2009 06:19 PM, Denys Vlasenko wrote:
<dvlasenk> on a slightly different matter: I want to unite
CommLayer, MiddleWare and Utils into Utils
<dvlasenk> They are all user in the same way: a common utility functions for
daemon/applet/CLI.
<dvlasenk> any objections?
* jmoskovc is thinking ...
<jmoskovc> I wouldn't say that mw and commlayer contains "common utility
functions
<jmoskovc> ok, maybe merging utils and mw makes sense
<jmoskovc> but i'm against merging commlayer into utils
Let's look what is in these directories.
They do not contain a significantly massive code:
CommLayer:
CommLayerInner.{h,cpp} -> warn_client(str), update_client(str) and relevant init
functions
DBusClientProxy.{h,cpp} -> client's dbus comm (I plan to simplify this)
DBusCommon.h -> typedefs and #de3fines only
Observer.h -> simple class abstracting out DBUS/socket comm
MiddleWare: -> Plugin API
Action.h
Analyzer.h
Database.h
Reporter.h
Plugin.{h,cpp} -> Plugin trivial virtual functions
They are small enough to not warrant separate libs.
(We do not put strlen ans chdir in different libs either,
they are in the same one (glibc) even though the functions
are not related, right?)
We bundle CommLayer, MiddleWare and Utils into single rpm,
abrt-libs-0.0.8.5-1.fc11.x86_64.rpm,
so user can't install only Utils. This is understandable since
we almost always use all three of them:
So, what say you? Is it ok?
--
vda
Ok, lets do it, if it's for sake of optimization, but I really feel more
like Utils should contain functions from abrtlib (which are 'utils' for
me) and commlayer, mw and the others should be in other library - or we
can combine it together and name it little more descriptive then 'utils'.
Jirka