[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gne]API

From: Rob Scott
Subject: Re: [Bug-gne]API
Date: Thu, 28 Jun 2001 12:48:51 +0100

i dont think ppl should really be concentrating on my crazy ideas righ now, but...
we can put things
er wait a sec.
what would gneGetUser("username") do?
what would it return?
and i dont think thats needed in the initial versions.

you can do that in c with a little malloc() hack.

int *brough;
int return;

return = gneSearchstring("string here", brough);

and in the function it simply does a

brough = malloc(n * sizeof(int));

n being the number of desired elements...

the return need not actually be used.

At 10:21 28/06/2001 +0100, you wrote:
that's pretty much what I said! Only I thought it would need
getPoolTitle... and the AID is implicit because that's the only
sensible way to call for it... looking for a digit is much quicker
and more logical than looking for a title string.

I also thought these might be quite useful:
@article = gneGetArticle("aid")
which get out all the information useful for that number/username.

With C, you know we were discussing returning an array from within
a function... can you d that (even if by a fiddle)? Becuase if not then
the two functions I put above would be a bit tricky woud they not?

Oh and we should write it so that clients can choose *not* to upgrade
the api for quite some time if they wish. So if their local API has:
        @article = gneGetArticle("aid");
and this translates to:
        $art = $dbh->prepare("select * from articledb where aid = "aid");
        @article = $art->fetchrow_array();
Then this will still work because it will still send a standard MySQL command
to the server. We should try and build this sort of lengevity into most of it...
make sure that commands wherever possible essential boil down to standard
MySQL/Perl/UNIX commands.

28/06/01 00:26:26, Rob Scott <address@hidden> wrote:

>very high level library
>gneSearchstring() which would return a n elemented array of integers, the
>integers being the aid#s of the
>relevant articles.
>gneGetTitleofAID() put in a aid#, get out a char.
>gneGetSynopsisofAID() put in aid#, get out char ...
>gneGetBodyofAID() ditto
>gneGetAuthorofAID() "
>that sort of thing.
>and the naming (numbering) conventions:
>c library version: 1.24
>this means protocol version 1.2
>(protocol upgrades only come along rarely, and dont need bugfixes in general)
>c library version 4 for this protocol. (library implementations need bugfixes)
>the 1 would only change when the api / protocol changed so drastically it
>made previous versions not work.
>At 21:10 27/06/2001 +0100, you wrote:
>>I'm still a bit confused as to the point of this api... are you saying
>>you want to standardise *all* commands used by the client (inc.
>>the ones that actually *fetch* the stuff, like select(....)) ?
>>Or will the api just be to standardise complicated things like
>>search queries, so kind of like putting the textsearch thing u found
>>into a standard GNE library/module made specifically for gne?
>>27/06/01 22:54:32, Rob Scott <address@hidden> wrote:
>> >we only need like     5 functions to start with, guys.
>> >im working on it.
>> >
>> >mainly things like
>> >int foo = gneSearchstring(char brough, *int toby)
>> >returning the aid#'s into an array in toby.
>> >foo probably being the number of elements put into the array to simplify
>> >things for the programmer on the end.
>> >
>> >
>> >_______________________________________________
>> >Bug-gne mailing list
>> >address@hidden
>> >http://mail.gnu.org/mailman/listinfo/bug-gne
>> >
>> >
>>Bug-gne mailing list
>Bug-gne mailing list

Bug-gne mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]