[gchartman-devel] Re[3]: todo

[<chr...@is...>]

> Christian, thanks for the list.. Some of the things I was looking at ,
> as in modules, look like they are in your short term list. Most of
> the things I wanted to do centered around the database .
> Setting gnome-db fto use other databases, even though
> I mainly use MySQL is something I think I would like to
> work on, along with the database format.

Yes, a generic database interface is a must. Gnome-db is probably the
best choice right now, because they provide gnome integration and
nifty widgets, and last but not least they support a lot of database
systems (they have a unixODBC driver, and unixODBC in turn knows
lots of databases). Problems that I see are: Gnome-db is currently
quite a moving target, and it relies on other quickly evolving
technologies (like bonobo, oaf). This makes compilation harder,
since you have to be up to date with all these things. Since I'm
rather bandwidth impaired (currently), I cannot afford to do cvs
checkouts from all those projects. Lacking documentation and
unstable snapshots don't really make things easier. I also
use some sql functions from mysql which might not be provided by
gnome-db, like soundex(), but that should not be a great problem
since they are not critical.
 
> I was thinking about the database format, and I was thinking
> a flexible formatter or compiled in modules might be better.
> I know a few people who have access to stock data in SQL
> format, but with a different format. I think it may be
> better for gchartman if it were flexible so that a person
> could run from his Oracle server at work, that has a much more
> complex data structure.

The current database format is a mess, mainly because I kludged it
together instead of designing it. I think it would be good to be able
to let the user adjust gchartman to his database. But the flexibility
that can be supported is limited by complexity. I can very well imagine
to have some things configurable, but other things not. As an
example, I would assume that all stocks with all their data are stored
in a singe table, identified by an ID column. Another table would
contain the ID, stock name, ticker symbol, etc. Now, one could let the
user adjust the name of the tables and columns used to look up data,
but the basic layout would stay the same. To support *any* kind of
database layout, one would probably end up with 1 query per data quantum,
which would make things flexible but slow. And the user probably would
have to supply the queries.

I'm not quite sure I understand what you mean by compiled in modules.
Do you mean to have different modules supporting different kinds of
database layouts? I think one should be able to adapt to a database
layout without writing code.

Another point is: *what* should be stored in the database? Currently,
everything goes into the database, videotext settings, chart configurations,
category contents etc. At some point I think it will be better to
put this data into some xml file somewhere in the users home directory.
This would be better for multi-user environments, it would not pollute
the database, and the database could even be read-only. Which brings me
to my next idea: A 'read only´ mode that could be selected at database
login time, guaranteeing that the database will not be modified.
It would be useful if one wanted to use a database at work (at a broker
house for example) without taking any risks or if one simply didn't have
the privileges.

> And adding open, high, and low to the database
> fields.

I know that these should be there. When I started populating
my database I had no data for them available, so I didn't include them
all :( stupid me
 
> I have some code for a database editor/viewer I can put
> in, but that might be something to look at after the database
> stuff is looked at.

Yes, ofcourse. There's also the gnome-db database browser widget,
which seems to be able to do some things too. Anyway, first the
database layout will have to be redesigned. I think that I
probably won't bother now to store a tree of chart items in the
database, but I will move configuration data to xml files soon.
I will modify the modules such that they store their information
in a readable way in an xml file, and not as blobs (don't know if
that is even possible).

Phew, long mail. In conclusion, I think we can start to discuss/design
the database layout, because adapting to a new layout will only get
harder the longer one waits. In my opinion, a new layout should be
done first, and then a flexible way to support different layouts
can be added. I think configuration data should not be included in
a new layout, but stored in xml files. Currently I'm making the
code more readable by gnu-ifying function and variable names.

By the way, the 'channel´ module seems to be rather broken. It doesn't
behave the way I want it to, so you better not use it too much.

No more time now,

Bye

Christian