Hi! First, this is not a solution proposal nor critiques for previous decisions. I just want to express the problems I'm seeing.
Firebird codebase is becoming more and more difficult to change/extend. Some not good code/concepts are being introduced everywhere, added with some bad previous code/concepts/architecture... Many of this are internal problems becoming public with plugins. It will make things much difficult to fix/change later. - IStatus (1): It's not clear what is this when interacting with external code. Provider functions clears it when entering but no other function does it. It's not clear what callers should do to check states. - IStatus (2): It should manage its memory. Depend on circular buffers in its implementation is just wrong. - Automatic Exception->IStatus and IStatus->Exception conversions: I tried to implement this, macros would generate methods that check status automatically or catch-and-convert exceptions. In the end, I just lost time. Mentioned IStatus problems and usage of warnings as you want to maintain make that an impossible task. Current code that manually enclose or check exceptions are ugly and error-prone. - IMaster: In a perfect world, we would not have static variables, but variables in singletons (per-engine/yvalve). In this perfect world, an user would be able to load two different yvalve (embedded client) and a single engine DLL would work if loaded in the two different yvalve. I don't want to propose this requirement, but IMO, that usage of how code (engine, plugins, etc) catches the IMaster pointer is just ugly. AFAIK, it will make impossible that user loads two yvalve with then loads two different engines, as the engines will call a yvalve function (fb_get_master) who cannot be guessed from what library it must be called. IMO, IMaster should being passed as parameters, and not like current. - Character sets and plugins: At some time in the past, Jim wanted to deprecate charsets and use just UTF-8. I was opposite to this idea, and I probably still am, but it's a fact that character sets and plugins are a difficult thing to document and integrate well. - Checkouts/Checkins: The interaction of checkouts and checkins in the engine is not clear in regard to plugins. AFAIK this was not necessary (external engines first implementation work without some of them introduced later), cause the reentrant locks still work without them. If it's not necessary, why do some of them (checkouts) were introduced? What if a checked-out plugin codes calls a non-provider API function that enters deep in the engine? This problems is also related with the tdbb still being used. - Metadata: One of ugliest code part, and never well worked if pushed hard (say, DFW problems), some of problems was masqueraded with per-user cache. But I doubt external routines would work well (say, an external function being loaded tries to call himself) in the moment. - Pools x refcounters: I personally hate to use pools (and yes, I hate the refcounters too) and the cost of carrying them, but at least it was consistent in usage. But now, refcounted objects are created in the global pool, while it's internal objects may or may not be in the same pool. - C++-03, boost, std C++ library: C++-03 is there finalized, but we're still using only std C library. Compilers vendors are eager to implement features and marketing it. Boost became an almost standard thing, with many good libraries, but no, we cannot use it! We cannot use the std C++ library. We rewrote thread support, we rewrote multi-thread sync. objects and many things available. We cannot write C++ code usable internally in Firebird and available to our C++ users. We have our strings, we have our exceptions and everyone should adapt to it. We probably would not upgrade to C++-03 in this decade by the current police. Adriano ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
