[IAEP] Alpha API Docs are up.

[Martin Dengler]

On Mon, Jun 09, 2008 at 10:49:53PM -0400, Albert Cahalan wrote:
> On Mon, Jun 9, 2008 at 4:31 AM, Marco Pesenti Gritti <mpgritti at gmail.com> wrote:
> > On Mon, Jun 9, 2008 at 7:51 AM, Albert Cahalan <acahalan at gmail.com> wrote:
> 
> >> I'm also not seeing how I could call this from, say, FORTRAN.
> >> Usually people explain things in terms of the C language, allowing
> >> most any language to call the API. If you're not doing that, then
> >> the next best thing is to describe things at the assembly level.
> >
> > You obviously can't call this in fortran, since it's python API.
> 
> This is extremely limiting. I hope you will fix it ASAP.

FORTRAN has a C FFI and dbus has C bindings.  Sure, that's unlikely to
be useful/desired by anybody in the future, ever, so I'm not sure why
you're asking.  The current languages vaguely supported[1] for
Sucrose/Fructose/Glucose are keeping people busy enough.  On what do
you base your argument for the priority of the work you're calling
for?  What FORTRAN developers are limited by the current system?  I
hear some FORTRAN developers are limited by the problem of writing
state machines[2].

> All API code should be language-neutral

Sounds like a bug you could file, with use-cases or specific problem
areas (like you mention the journal, below).  What do you think the
priority will be vs. other issues?

> >> I couldn't find anything related to the journal. I'd like to see
> >> an explanation of how to implement an alternate journal. Suppose
> >> that I wanted to write a replacement. What are all the interfaces
> >> that need to be implemented? Assume the replacement will be written
> >> in some other language, possibly COBOL. How does the replacement
> >> get installed and take over?
> >
> > The journal API is exposed through dbus. We will likely document it on the wiki.
> 
> Great. Please don't forget the "take over" part.

Are you planning a COBOL replacement of the journal?  Is someone else?
I didn't realize COBOL had an accessible, i18n-able widget set.  It's
easy enough to work with dbus via C, if you really want to use a
non-dynamically-typed, cumbersome-to-introspect language (using dbus
from without a language-supported framework is already not
recommended[6]).  Or did you mean the datastore?  There have been a
few efforts at re-writing it, all well known to readers of the obvious
mailing lists[3,4,5].

> The idea is that a user could even uninstall the current journal and
> convert the database to the format used by his journal replacement.

It's a very interesting idea, but why should this (replacing the
journal, converting datastores) be a goal for Sugar 1.0?

Martin

1. http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/Design_Fundamentals#Transparency
2. http://lkml.org/lkml/2004/1/19/139
3. http://lists.laptop.org/pipermail/devel/2008-May/013716.html
4. http://wiki.laptop.org/go/Journal_and_Overlays
5. http://wiki.laptop.org/go/Olpcfs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.lo-res.org/pipermail/its.an.education.project/attachments/20080610/bffa72d4/attachment.pgp>