Alec leamas a écrit :
Ah, we got a discussion :-)
Yes :-)
Summarizing advantages: Aurelien sees the config file and the
more fine grained phapi logging, Andreas the console logging
and I an established design pattern.
I don't understand what you mean with "console logging" being an
advantage. I guess you are referring to this part of your previous message:
"""
Before recent changes, we had debug output at the console, which just
isn't acceptable. But now we have no logging at all, which is also bad.
"""
Before recent changes, everything was outputted to the console:
debug,info,warn,error,fatal. Now debug is off by default (but can be
enabled on a component basis). To me this is different from "we have no
logging at all". Or am I missing something?
Applying the way of work described in the article in this case
might be.
- To make 2 (possibly 3) minor patches to
current log system which will run using the
same logging code. These are about
printf formatting (refactoring)
What do you want to change to printf formatting?
> and creating
a facade for the configuration stuff
(LogConfig).
- After this there would be a major patch with
the new backend, but not hooked in
- The final patch should just be applied to
Logger.h and LogConfig.h, with a clear option
(#define) to use either logging system during a
transition period. That is, we have current
system in place, and it could be used with a
#define (not runtime switch, it's really to
much work).
-At some point in the future, we remove a number
of #define and uses just one system...
The "new backend", is the one using LogConfig I guess. Do we really need
a new backend for this? Can't we extend the current code to use LogConfig?
A natural way to work would be that I first commit the minor
patches, and then prepares the major patch and attaches it to
the #1856 for review. At this point there will also be a sketch
for the third patch.
I believe you would get more feedback if you post your patches to the
mailing list: not everybody is subscribed to [EMAIL PROTECTED]
> The thing with working incremental is that I really need to
> check in, it's hard to administrate otherwise.
Beware! writing such things on a developer mailing list is like invoking
a Git/Darcs/Monotone/Mercurial/Bazaar zealot :-)
You might want to have a look at Quilt, a patch system built by Andrew
Morton. I used it for a while in the past to maintain a set of patches
against some large Subversion projects like kdepim.
Aurélien
_______________________________________________
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
