> 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.
for me, gnome-db (0.1.0) is not stable at all. The included applications
regularly seg-fault, especially anything using their db browser widget.
As long as their applications crash I'm not even trying to use it.
> 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.
That's very interesting. Basically a chart can be displayed of any data stored
in QuoteV (which I renamed to quote_vector). So it should be possible to support
different kinds of data sources. If everyone had free broadband internet access,
why store any data at all? It's all on the net! Just get it from a website/data
provider
when it's needed. Another possibility: support streaming data. A piece of
code could use a reverse-engineered livecharts.com protocol for example, and
provide a new quote_vector once a minute. By the way, recently I stumbled over
the FreeMarket project at SourceForge. It's pretty interesting, they use a Corba
based architecture and have streaming data support.
> 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.
I think it will be sufficient to have configurable column and table names,
and to make some features optional, so that one can fall back to end-of-day
data only if nothing else works. It may also be possible to use sql views to
increase compatibility.
> 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 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
Yes, I also thought about it. And it would not be a big deal to put these
data access routines into real modules (which I think would be good).
> 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.
Currently I'm working on 2 things:
turning the list of chart instances into a tree & making modules generate a new
(or modifying the) quote_vector.
and
putting configuration data into xml files in the users home directory,
1 for global configs, 1 for local configs, 1 for categories, 1 for
videotext settings,
So the priority for getting configuration data out of the database is pretty
high.
> I would think that making a .gchartman directory in the users
> directory would probably be best.
It's already there :) Videotext pages are stored in ~/.gchartman/videotext
by alevt-cap. Once capturing is done they are read from there and parsed by
gchartman.
> 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 think a simple 'read-only' toggle in the login window should do the trick.
> I am wondering if it gchartman would have to check to see if it had
> write privileges, and how would it go about it.
Hm... easiest way: just try it and check for success. not very elegant...
> > > 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 :-)
Currently I'm concentrating on the german market because I get lots of
information (including quotes) from german tv. Also the german market (Neuer
Markt)
is a lot easier to keep an eye on (just ~300 stocks).
> 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.
Do you mean the data itself? I've thought about it. There's two possibilites:
- rely on gnome-db. AFAIK they want to provide a way to export any supported
database into an xml file.
- write all the necessary data access routines, which should not be *that* hard,
once all data accessing code is put away into functions.
I think the db layout is now rather important, too.
> 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..
Hopefully.
> what xml parser are you thinking about using ?
I've experimented with libxml aka gnome-xml. The api is pretty ok, and it has
one big advantage: Just about everyone has it. It also seems to be fast enough.
Of course any data has to be sprintf'ed to strings prior to saving, and it
must be parsed upon loading, but I think that is inevitable and still faster
than a (potentially slow) database access.
> what do you mean by 'gnu-ifying' names ?
Turning variable names like 'QuoteV' into names like 'quote_vector'. It's
longer,
but it's also clearer. All variable and function names are now lowercase,
underscore-
seperated word sequences. Types are first-letter-uppercase-no-separator (like
ChartInstance).
This is the same naming scheme as in gtk. It also means that if you wrote any
code,
you'll have to change some things probably.
|
