[gchartman-devel] Re[4]: todo

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

> FROM: ist.luDATE: 10/13/2000 10:34:56SUBJECT:  Re[2]: [gchartman-devel] Re[3]: todo
> > 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.
>

true, true. I do use the table widget and that seems pretty stable
except for
cutting and pasting ops are not working.



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

exactly ! Say I have a custom indicator I wrote or say the output of a
neural net program, etc, etc.And then stored it in my MySql database.
I then could use it in gchartman.

Supporting streaming data would require a change in QuoteV to suppot a
time marker ( as opposed to end of day ). Other than that everything
else is the same. Instead of the date, followed by price, it would be
time+date followed by price.

I also saw the free market project. it looks like they want to make a
linux clone of Omega Tradestation. It is interesting.

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

That is pretty much what I meant. configurable column and table names
and the SQL staments to retrieve the data. If you have a relational
database , you can use alias in the SQL statments to change the column
names, i believe. I will have to check.


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

true.

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

Cool. But I don't have that directory. I don't use videotext., so it
probably never got created.

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

not elegant, but works. Just remind them that they don't have write
privs.

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

No, I don't mean about exporting xml data. Most of the time, the data
will be going INTO the database, not exporting. If someone really needs
to export in xml, maybe that exercise should be left for themsleves.

I meant define what the data access routine interface should be. I can
write them, but I wouldn't want to write something that would be
incompatible with what others are doing. I think some thought needs to
go into defining what the interface should be, before writing them.

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

I still use Jim Clark's expat. Probably because it is so old, and there
wern't too many parsers around back then. As if it was that long ago. I
think I will have to muck about with libxml, see what it is like.

I think speed should not really be that much of an issue. For xml , I
think I would go for ease of use, availabilty and  stability over speed.
xml is xml.

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

I ususlly use that style for filenames. So I wouldn't have to make any
change. I got my shop to standardize on that form. The advantages of
writing the style guide ;-)

wenzi