(oops wrong list :) [Fwd: Re: Schema]

> The problem I see is that if we start counting up what we think a user
> could need we will for sure miss at least one thing. Doesn't matter what
> it is, but there will for sure be a Joe User that misses something; call
> it a variant of Murphy's law.

> It is a great chance and could be a very unique feature to our GPE
> applications.
> And not only for feature-ism. I also think that it can be very handy if
> not necessary to do so. For example name suffix was mentioned. We cannot
> think of all suffixes in all languages now. We will for sure miss many of
> them. So we create a table for them! Internationalization would become
> much easier.
the suffixed and prefixes mentioned were just examples, my suffix and
prefix fields are free strings, so they can be anything (a gui could
provide common examples but the data-rep is free.)

> Then for the synchronization part.
> This is really a problem and will persist for quite seme time. There is no
> real standard especially not on the fields and datatypes. VCard is a de
> facto standard and we should closely follow it as far as possible. But it
> should not limit us or the user. We should support it in a way so that
> data exchange is possible. But if we can have more flexibility on top of
> it we should go for it!
> We could for example create a default set of tables that contain the
> settings that are proposed by VCard. We could even make those
> "unchangeable" for the user so that the user will always be able to
> exchange data with other devices. But there should be room for the user's
> creativity.
>
> So, how can we proceed to come to a final conclusion and decision?
> Should we have some kind of a vote?
yeah why not,
Ok so thats one vote for user-defined contact types :)

i'm beginning to come round to yours and Derrell's way of thinking, so
you might have to find somebody else to oppose the idea :)

I still think the basic types should be fixed in a header/module at a
code level somewhere, and possibly reflected in the contact type
database that way apps can rely on being able to deal with the basic
types and then do their own thing with user-defined ones.actually i
guess they should be in the table (to enable proper joined selects)

hmmm (pondering)

There is a problem with having the standard/user-defined contact types
both in the database in that the typeIDs of the user types will start
from where the pre-defined types left off, which will cause a future
compatibility should we add more user defined types, so we want a way of
all the new user-defined types starting with a typeID > some constant
which is about (0x0000ffff) but this means that to add a user-defined
type you would:

select max(type_id) from contact types where type_id>USER_TYPE_BASE;
if that didn't return a row then new type_id will be USER_TYPE_BASE,
else it will be max(type_id) +1

i18n isn't (typical for me) something i had thought about, the
predefined types could just have a translation table in code using
gettext or whatever, but in the database this becomes more of a problem
(i'm not even sure how/if sqlite handles non-ascii strings)

owen

-- 
Owen Cliffe, Ph.D. Student, Dept. Computer Science
University of Bath