-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Aug 17, 2009 at 06:56:47AM -0300, Ismael Luceno wrote:
> The problem with both solutions is that they have the same negative
> effects as "g":
> 1) Expose something directly to the whole system.
> 2) Implementations can't be swapped.
> 3) Functionality specific to some domain can't be moved outside the
> core.
>
> Maybe we should unify and store everything on a single DB, thus
> allowing to store any kind of content, which would descend from a
> special node representing it's domain.
>
> In that case, lists would not be appropriate anymore. The best
> structure IMO is a B-tree. It's a bit more difficult to iterate over,
> but provides fast lookups and is more memory-efficient than a list if
> it's balanced (we can take that cost because the list is mostly static
> once we loaded all the services needed).
>
> BTW, when searching, on most architectures, with a few exceptions like
> x86, calling a function is not so slow because the compiler can
> potentially improve the loop by simply saving the right direction on a
> register. Yet it's unable to perform any other optimization. On x86
> everything becomes worse because we have the stack in the middle, which
> is very slow. So we must avoid calling a function if possible.
Now I see. Ok then, forget all my propositions until now, I guess they no
longer make sense. Although I shed a tear because I personally liked the yield
function call recipe. :-)
The thing with the generic DB is, that, depending on the type of data storage
model we choose, we can get good or bad results depending on the state of our
program. A B-Tree gives us good performance when we e.g. store services, their
states and dependencies in it. Sorting would rely on a criterium like the
dependencies. But if we store other things in the same DB instance, too, we'll
probably make thing inefficient because we cannot choose a good algorthm for
sorting/insertion.
But that's just theoretical. In the end, I'd like to stick with that idea and
implement a content-agnostic DB first along with generic accessor functions,
then define data types for whatever thing we store, and provide a well-defined
API, e.g. through macros, to hide the details of the data types what would, as
you said, allow us to change things under the hood and keep the rest going
instead of exposing to many internals.
-- Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
iEYEARECAAYFAkqJLecACgkQhS0drJ3goJKFXwCfUnC22gtmFcJxIlgKYrEMmb+J
MfUAn2WKXJgAcRbJwK8cv+FjAhOj722o
=LBFa
-----END PGP SIGNATURE-----
--
_______________________________________________
Initng mailing list
[email protected]
http://jw.dyndns.org/mailman/listinfo/initng
