> From: David Jencks [mailto:davidjencks@...]
>
> On 2001.05.08 15:18:41 -0400 Leandro Dutra wrote:
> > Should I subscribe to your firebird-admin and ib-architect lists
> > by
> > myself or will you forward this to them?
>
> Subscribe to ib-architect. This is not appropriate for ib-admin.

Did it already, and I will not forward any more messages to ib- or
firebird-admin.

> Firebird is a fork of interbase by virtue of Borlands apparent

Is there any documents about the roadmap of Firebird?

> > Unfortunately I believe the use of GPL-incompatible licensing is
> > a
> > much more serious question than usually realized. But
> let's at least
> > talk
> > and see what can we do about that.
>
> We have already gone beyond my expertise about licenses.
> What constraints
> are you operating under with regard to licensing?

Mainly self-imposed ones... I do believe that only copyleft
(http://www.gnu.org/copyleft/copyleft.html) for example GPL or to a lesser
extent LGPL) really protects the users' freedoms and the rights of the
developers.

> > > --What is the relationship to the outside world?
> >
> > I think I didn't understand what do you mean...
>
> For example, how do you inform the db that you want a domain
> to correspond
> to an object type in language X? How does the db recieve or
> deliver the
> object in an appropriate form? Can the db do theta joins on
> objects from
> different languages? etc.

One of the features of Tutorial D is the idea of "Possible
Representations", or posreps. Even if the actual representation of the
object is a matter of the physical layer, and then outside the scope of
Tutorial D (in effect, implementation-defined), for each domain it should be
possible to specify at least one posrep accessible thru a function.

I think posrep would be answer enough for these problems.

> > It's been a long time since I've studied OO, and now I am quite
> > unfamiliar with OO jargon. What exactly do you mean by
> domain members?
>
> A domain is a set, I mean an element of one of these sets.

I would say it different... a domain is a type, possibly
user-defined, that is, an (possibly infinite) enumeration of scalar values.
Perhaps what you call domain member would be a scalar value?

> > > --Are type hierarchies supported?
> >
> > The Third Manifesto has its own inheritance model, which I won't
> > be
> > able to explain here. You would really have to buy the book.
>
> I know, I guess I'm asking if you are planning on implementing type
> hierarchies and if so how.

That is a whole section in the Third Manifesto. If you do not have
access to a copy of it I can try and make a summary, but it is a big issue.

The shortest answer is that Tutorial D should support hierarchies,
but in its own terms. Then there's an open issue about mapping this to host
OO languages if need be.

> > Perhaps you have in mind the SQL definition of domain. AFAIU, a
> > SQL
> > domain is just a named SQL simple type definition, not a domain as
> > defined
> > in theory.
>
> You have to start somewhere, firebird implements something
> similar to sql
> domains. I don't think you are constrained from joining
> different domains
> that happen to have compatible base data types.

I think this should be indeed possible, but thru explicit or
implicit type casting.

While firebird support for SQL domains could be seen as a starting
point for proper (in the Mathematical sense) domains, probably we should
keep it clear in our minds that they are quite different concepts.

> constant or even bounded. So it is simplest to say, OK, we store all
> objects as blobs, and we keep track of id, actual type,
> hashcode, and maybe
> length. blob basically means .... blob as in "the blob that ate
> cincinatti", we don't know anything about what is inside.
> This corresponds
> pretty well with Date's idea of an object.

I think so. We should just care to only allow operations as defined
by your "actual type". Obviously the user can have a more direct access to
any posrep of the type.

For the definition of operators, including the posrep ones, each
domain should have operators to expose the actual, implementation-defined
representation of the scalar values. AFAIU this would expose the binary
data in the BLOB.

> Look at the IBPhoenix site, they have the most old docs, and
> I think info
> on both of these.

I will.

> > Do you think BLR can be extended enough for Tutorial D support
> > without breaking SQL support? If this is not possible we
> would need a
> > fork.
>
> It seems a bit premature to jump to conclusions on this. My
> guess, knowing
> very little about BLR, is that the changes to blob structure I outline
> would be consistent with SQL support. I don't know what else would be
> needed.

Neither do I. So for now we should consider BLR enough.

> > Yes, this may be thorny indeed. Keep in mind that in Tutorial D
> > we
> > would need not only to add data types, but create a generic
> mechanism for
> > user definition of new types and its operators.
>
> Requiring operator support is kind of implausible I think. The blob
> storage mechanism I outlined above plus adding/modifying the existing
> domain blob subtype constraints to declared type constraints
> ought to make
> equality joins on objects doable.

Indeed the equality operator is a minimum must. Perhaps internally
all user-defined domains could be subtypes of BLOBs. But if Tutorial D is
computationally complete, and even more if we add support to the definition
of functions (and thus perhaps also operators) both in Tutorial D and other
languages such as Java or Scheme (Guile? Lisp?), then operators should be
plausible further down the roadmap (that we haven't defined yet).

If this come to pass it will be a big project, encompassing many
developers and many years. We don't need to, and indeed we can't, have it
all in the first release.

> i personally am running low on time. If you come up with
> some concrete
> proposals about how to proceed I would be interested in
> seeing them, but I
> doubt I can participate actively.

All right, this is pretty much incipient as of now.

> If you are unfamiliar with dbms internals, you might want to
> investigate
> more before proceeding much farther. One possibility might
> be to start
> with a simpleminded db such as hypersonic, which I believe is
> pure java, in
> memory only, "rdms". Its quite small, it might be easy to
> understand how
> it works.

Thanks... I have thought also about using Leap for this. Can you
give me a good URL to get started on hypersonic?



--
_
/ \ Leandro Guimarães Faria Corsetti Dutra +55 (11) 246 96 07
\ / Amdocs Brasil Ltda, São Paulo +55 (11) 3040 8913
X http://geocities.com/lgdutra/ mailto:leandrod@...
/ \ Campanha fita ASCII, contra correio HTML mailto:lgdutra@...