[opdev] status of the API (30 sept)
Pierre Lindenbaum
Team to visualize the relationships between the snp and
pubmed/omim/etc...
2) I wrote the structures for Operon and OperonDatabase , but instead
of storing each OperonDatabase in the Operon structure like this
struct Operon
{
OperonDatabase* databases;
(...)
}
I preferred linking each database to one operon
struct OperonDatabase
{
Operon* my_operon
}
because I guess a database could be opened at multiple times in the
same request..
3) main concerns:
* avoiding any code mixing your 'model' (berkeley) and the 'view' (html)
* avoiding to use the global variables in common.c
* splitting common.c and bdenv.c with one file for each logical structure
* creating a 'struct ApplicationConfig' for each 'main', instead of
using this big 'APPCFG'
I'm a little bit lost in all the methods in common.c, bdenv.c , I pain
to do the reverse ingeneering...
But also, where should I stop ? should I re-write all Mario's API ?
should I re-write each application ?
4) I now identify 'unique' fields in the structures (e.g. 'acn' in
MPanel'): methods are now created on the fly to check if a value
already exists in the database
5) I'm trying to re-create the tool 'spindle.c' with my library
5) most of this 'C' code could be ignored with java without changing
Mario's base API. For example, creating a form to input a new MPanel
would be straightforward to write (and would easily implements the
users authentication+session )
Pierre
Pierre Lindenbaum
> same db:
int method2()
{
> Calling DB->open is a relatively expensive operation, and maintaining a set
> of open databases will normally be preferable to repeatedly opening and
> closing the database for each new query.
>
>> 3) main concerns:
>> * avoiding any code mixing your 'model' (berkeley) and the 'view' (html)
>> * avoiding to use the global variables in common.c
>> * splitting common.c and bdenv.c with one file for each logical structure
>> * creating a 'struct ApplicationConfig' for each 'main', instead of
>> using this big 'APPCFG'
>
> Indeed Pierre very good concerns.
>
>> I'm a little bit lost in all the methods in common.c, bdenv.c , I pain
>> to do the reverse ingeneering...
>
> Understandable. Drop them. There is no intentions of re-writing all
> methods in the old API.
>
>> But also, where should I stop ? should I re-write all Mario's API ?
>> should I re-write each application ?
>
> So you got to this point.
>
> Then it is probably reasonable to ask if your current API can be used
> by others. Do you think is ready so that I can write an application
> with it? Of course, I will not expect every method I wrote before,
> but the fundamental part, to open some dbs, and do some transactions.
> If the answer is yes, maybe you should stop, and we proceed with
> another meeting with Simon, you and I.
>
>> 4) I now identify 'unique' fields in the structures (e.g. 'acn' in
>> MPanel'): methods are now created on the fly to check if a value
>> already exists in the database
>
> Great !
>
>> 5) I'm trying to re-create the tool 'spindle.c' with my library
>
> Related to 3, it seems you API is ready.
>
>> 5) most of this 'C' code could be ignored with java without changing
>> Mario's base API. For example, creating a form to input a new MPanel
>> would be straightforward to write (and would easily implements the
>> users authentication+session )
>
> OK Pierre, this I really want to see how it works.
>
> Mario
>
>>
>> Pierre
>>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
Pierre Lindenbaum
> I don't see any problem with this preference, yet opening and closing
> same db:
there would be a problem if two methods need to open/close the same database
void method1(OperonPtr operon)
{
DatabaseA_Open( operon);
(...)
method2( operon);
(...)
DatabaseA_Close( operon);
}
void method2(OperonPtr operon)
{
DatabaseA_Open( operon);
(...)
DatabaseA_Close( operon);
}
>> But also, where should I stop ? should I re-write all Mario's API ?
>> should I re-write each application ?
>
> So you got to this point.
not really, but as I generate most of the files, there will be a time
where I'll have a default API for each database (searching,
inserting,...) but I wonder what I'll be the next step: rewriting each
tool ?
> Then it is probably reasonable to ask if your current API can be used
> by others.
again, it's too early. I did'nt have even tried to link all my *.o .
But the skeleton for each file is here.
> Of course, I will not expect every method I wrote before,
> but the fundamental part, to open some dbs, and do some transactions.
open/close/tranx/add/remove should be soon available
>> 5) most of this 'C' code could be ignored with java without changing
>> Mario's base API. For example, creating a form to input a new MPanel
>> would be straightforward to write (and would easily implements the
>> users authentication+session )
>
> OK Pierre, this I really want to see how it works.
so I will write a test with tomcat (the files will be generated using
the very same xml description of the C structure).
I just had a talk with Florence and her team: She'd like me to improve
a tool I wrote for them last week (
http://plindenbaum.blogspot.com/2008/09/what-is-in-list-of-snp.html ).
I'll need a few days to create an interactive interface that would
browse the results.
Pierre