Re: [gchartman-devel] Re[3]: todo

[<we...@ra...>]

>
> 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 agree on the gnome, and helix code parts. I download
all the Helix code libs, etc. ( bonobo et al. ) Not only is
it a moving target, I don't think it is that stable. My Redhat
6.2 system wierded out on it.

gnome-db , is nice, but I am not sure if it is something
you can easily use without CVS , and a decent sized pipe.

>
> 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 was not thinking about supporting ANY kind of database, I was thinking
about ways to make it more flexible. If you always look at end of day prices,
that's fine. But look at some tick data suppliers, where they only supply the
price difference from the previous tick.  But more to the point, I wasn't
speaking of ANY format, but more of a way to allow people to easily use
their existing databases. For example, after you do a query in gchartman,
it assumes the stock_name is in column[0].

I was just thinking of how to be flexible, the ability to support every
database and
supporting MOST users are two separate things. Looking for MOST users would
be better.


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

I should not have used the word "modules", my mistake.  what I
thought about was a data access set of routines. on the outside
generic functions, such as get stock list() for functions like
init_stock_combo() and others.  If your particular rig
was special, you could change what was needed there. Since
it would be a C file, it would have to be compiled it.

also , it would make an easier upgrade path to gnome-db


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

I think global settings should go in the database. However , I think a global
xml file would be better, I don't know how high that is on the priority list.
User configuration files should DEFINITELY go in the users home
directory.

I would think that making a .gchartman directory in the users
directory would probably be best.

The read only idea is a good one. My database here allows certain log ins
only in read mode. they don't have the permissions to modify the database.
That is on the database side. The problem with that is that the user
interface must reflect the certain things are unchangeable. Putting it
in gchartman itself instead of the database does eliminate this problem.

I am wondering if it gchartman would have to check to see if it had
write privileges, and how would it go about it.

>
> > 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 plenty of US data. let me know if you want any :-)

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

def. a long email. but good stuff...

I would like to discuss the database layout also, and I think the sooner
the better. I think we should look at how it will make programming easier
and stay on the path to gnome-db. but as for flexible ways, i wonder if
we can also just store it in the xml file. what I think , is that most data
formats
will be very , very similar. the major differences will be in data format
, column position, time format, and SQL calls. I think a good part could
be abstracted out..

what xml parser are you thinking about using ?

what do you mean by 'gnu-ifying' 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.
>
>

thanks.

--
wenzi   we...@we... http://www.igerg.com

Him:    "Your skin is so soft.  Are you a model?"
Her:    "No,"  [blush]  "I'm a cosmetologist."
Him:    "Really? That's incredible... It must be very tough to handle
        weightlessness."
                -- "The Jerk"