On 1 Nov, 2006, at 10:12, Phillip J. Eby wrote:
At 09:31 AM 9/28/2006 -0700, Grant Baillie wrote:
Hi, Phillip
This all makes sense ... I imagine the API would provide typedefs for
common non-primitive types, like signed integer, or floating-point.
Out of curiosity: why the restrictions on length of Bytes and Text
(and the size of Integer)?
Sorry for my month-delayed reply; I somehow missed this message the
first time through, and just saw it mentioned in Katie's September
post summary. :(
The restrictions were based on the current use cases for Cosmo-
Chandler integration. Nothing stops us from adding more types
later, should the need arise, however.
The Integer definition was chosen because 32-bit signed integers
are common to most programming languages, especially Python and
Java. The bytes/text size requirements were based on the need for
efficient relational implementation on the Cosmo side.
Ah, cool.
And yes, we would have typedefs for common non-primitive types.
I just checked in the type and record-level API (osaf.sharing.eim)
yesterday, so you can see the docs for how to define typedefs and
type converters and such. Now, in fact, would be a good time to
begin deciding what typedefs and converters we would like to have
for our domain model. At the moment, I've only defined a converter
from 'int' to 'Integer', and haven't even registered any aliases
from schema.* type names to any primitive types. We would also
need to assign URIs for any types we set up in this fashion.
I have a couple of things I'm busy with this week, including writing
up some domain model documentation, which should help, indirectly,
with this, but I'll take a look next week.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
