[gchartman-devel] Re[5]: todo

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

[snip]

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

Or maybe one could have multiple threads and some sort of inter-process
communication
to signal that new data has arrived and that a new quote_vector is ready for
display.
 
> I also saw the free market project. it looks like they want to make a
> linux clone of Omega Tradestation. It is interesting.

I don't know Tradestation, guess it's some piece of professional software.
 
[snip]
 
> 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.
 
Yes, I think aliases are possible. Having user-adjustable sql statements is ok
as long as there are not too many, and sensible defaults have to be provided of
course.

[snip]
 
> > > 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.

Right. I modified this now: ~/.gchartman is now always created and
~/.gchartman/videotext
only when you actually use videotext.

[snip]
 
> > > 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.

Yes, one should really think about things before coding away. Wish I had known
that 1 year ago :) Actually I knew it but I didn't care :)
But it won't be long until I will be brainwashed into not knowing any other way,
because I now have lots of courses on these things.

[snip]

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

I don't know expat, but then I'm new to xml anyway. libxml seems pretty
straight-
forward to me, and it has the availability advantage.
 
Currently I'm working on the tree-of-chart-items-stuff, which means quite a few
changes,
and on the xml stuff. It will take 1-2 weeks at least until the next release,
because I'd
like to have *all* configuration data out of the database for it. But I can
upload
an intermediate version in a few days if you want it, or I can mail it to you.

Christian