On 03/18/13 03:40, Adriano dos Santos Fernandes wrote:
>
> - 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.
All called functions should clear it - that's how ISC API always used to
work with passed status vector. If someone does not - that's a bug.
>
> - IStatus (2):
>
> It should manage its memory. Depend on circular buffers in its
> implementation is just wrong.
Certainly. But this is not IStatus itself problem, it's implementation
problem. Memory should be managed by IStatus, but this should never be
expressed in any way in interface itself, moreover in some hidden way.
Remember that user may implement IStatus himself.
>
> - 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.
I do not like use of macros in the code cause they prevent debugging.
But may be in this case they may be used with care....
What about warnings - it's more interesting thing. According to standard
calls to database engine may raise *exception* and *completion*
conditions with completion conditions divided into *no data*, *warnings*
and other completion conditions. Sooner of all we should reflect that in
IStatus, but currently I have no good ideas how.
>
>
> - 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
Sorry, but some software (like IBE) makes it possible to explicitly
specify client library to use with specific database. I.E. unfortunately
we must be ready to have >1 yvalve per process.
> , 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.
PluginEntrypoint* startModule;
if (module->findSymbol(STRINGIZE(FB_PLUGIN_ENTRY_POINT),
startModule))
{
startModule(masterInterface);
Removed some code to make it visible better that IMaster is passed here
as a parameter to plugin module at startup. If you prefer another form
("not like current"), please suggest.
>
> - 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.
A fact? Not sure, but even if it's a difficult thing - what does it mean
for us? Do not have difficult things at all?
>
> - 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?
Can you be more specific here? What checkouts do you not like?
> 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.
Do we still have non-provider API functions that may enter deep in the
engine? This definitely worth solving.
I propose something like that may be present around blob filters, but
it's good idea not to make others guess.
> - 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.
You did not open new part of the world here. Per-user cache was
introduced specially to avoid a lot of that problems. Why? We want to
have FB3 releases in reasonable time.
>
> - 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.
Yes. And that's not a problem, though seems to be so at the first
glance. With refcounted object in global pool we provide stable pointer
to the outside world (and internal async calls: logically they do not
differ much from external API calls), that mini-object checks presence
of BIG internal object (which may be created in another pool), and if
present - calls it. Nothing bad happens.
>
> - 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!
Personally I prefer to avoid use of preprocessor, but who said we can't
use it at all? Specially if it does not cause debugging problems.
> We cannot use the std C++ library. We rewrote thread
> support,
Hmm...
Something new for me. There was a win-only code which solved
response-time problems with old thread manager. They were pre-fb3, but
both are gone in fb3.
Is it degradation?
> we rewrote multi-thread sync. objects and many things available.
As long as existing standard objects satisfy our requirements we use
them. But what to do if we need something more?
>
> We cannot write C++ code usable internally in Firebird and available to
> our C++ users.
And what about Delphi users who need same fucntionality? [Almost sure
that number of them > number of C++ users. ]
> We have our strings, we have our exceptions and everyone
> should adapt to it.
That wonderful std::string missing even trivial trim() function? No, please!
Well, I do not remember details why we stopped to use std::exception.
Something like it was suggested by Jim many years ago.
> We probably would not upgrade to C++-03 in this decade by the current
> police.
IMHO not main goal of the project.
------------------------------------------------------------------------------
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
