[IAEP] Alpha API Docs are up.

[Albert Cahalan]

On Tue, Jun 10, 2008 at 12:29 AM, Martin Dengler
<martin at martindengler.com> wrote:
> 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].

I can just as well use C++ or LISP as an example.

While dbus may have C bindings, that doesn't cover the
random sugar odds and ends.

Note that language support becomes easier if you
base it all on C. Python support becomes a wrapper
which should be fairly trivial. (and Java, and...)

>> 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 know where the priority belongs if you wish to
involve more of the free software community.
Converting everybody else to Python is far less
likely than converting you to FORTRAN.

Of course, there is the possibility that the Python
cabal does NOT want to involve the wider community.

>> >> 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].

I have some desire to attempt it in C, using SDL_Pango
for the i18n. It works well for Tux Paint. Widgets? :-)

I'd love to see numerous alternatives from different authors.
We can have a desktop metaphor journal, a CLI journal, etc.

I expect that many authors will prefer C++ with gtkmm, etc.

>> 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?

Nobody will write anything better if journal replacement
is a complicated process that ultimately requires hacking
on the existing journal. Without a viable drop-in ability,
such a project just doesn't make sense.