Language bindings

Honestly, as long as there is a well documented and maintained schema, I
don't care what bindings exist beyond a standard SQL interface. It should
not matter if you choose to use libPIM, I choose to use JDBC, and Kevin
Fisher chooses to use some Squeak->SQL binding.

But if you want to describe a high level interface that you think would be
useful, that's fine. :-)

        --- Noel

-----Original Message-----
From: mallum
Sent: Monday, February 11, 2002 9:25

Could I also suggest we maybe write a 'libPIM', this would wrap the
SQL calls and provide an api of simple PIM like functions; things like
PIM_addr_add_entry(...), PIM_addr_find_entry(...),
PIM_todo_get_entry(...) , etc....

This would give us some benefits;

  o We can easily have multiple front ends with out having to rewrite
    lots of ugly SQL into each front end.
  o It'd be easy to write bindings for other languages - Python/Perl
  o If the backend is changed from SQL lite, we'd only need to change
    'libPIM', not all the front ends.

Thoughts ?

  -- mallum

on Mon, Feb 11, 2002 at 12:01:44AM +0000, Owen Cliffe wrote:
> Ok cool, partly as an experiment in social engineering, would
> anybody (esp. pim app writers) feel like proposing a core schema for:
>
> - Contacts
> - Appointments
> - To-Do items
> - anything else anybody wants.
>
> as for extending, it makes sense to let apps just add tables which relate
> to the core tables in whatever way they want (so probably not normaised)
> sqlite doesn't support alter-table anyway, so doing anything other than
> adding new tables for app-specific data would be hard.
>
> I've just noticed that sqlite support transactions, which makes concurrent
> access very groovy (as the lib only locks the DB file during a commit)
>
>
> On Sun, 10 Feb 2002, Noel J. Bergman wrote:
>
> > > > SQL tables, I believe, but no one has proposed as formal schema.
> >
> > > If anybody is working on sqlite based code, it would be useful for
them to
> > > post CREATE TABLE sql code for any database schemas they intend to
use, so
> > > we can get some form of convergence for common schema forms...
> >
> > Personally, the good approach would be to agree on a schema BEFORE
people
> > get carried away writing a lot of code. A core schema that supports a
> > common approach to extend. Properly normalized, with samples showing
new
> > people how they should add new elements.
> >
> > --- Noel
Received on Mon Feb 11 09:29:00 2002