[Kde-finance-apps] Brainstorming requirements for an Alkimia Quotes Backend: Feedback/Reality-Check Needed Please :)

[Brian Cappello]

On Sun, May 23, 2010 at 2:48 PM, Alvaro Soliverez <asoliverez at gmail.com>wrote:

> On Sat, May 22, 2010 at 8:18 PM, Brian Cappello <briancappello at gmail.com>
> wrote:
> >>
> >> It is normally better to have more work than schedule. It often makes
> for
> >> amazing results, and if the work does not get finished, it makes
> planning
> >> for
> >> release n+1 easy :-).
> >
> > I like this philosophy very much :D
> >
> > I just "finished" putting together a Wiki page that's a lot more
> > readable/sensible than the above email, excess dreams included :)
> > For now, it lives at:
> > http://techbase.kde.org/User:Bpeller#
> >
>
> I'd only add to this "release early - release often" which does not
> equal to "release crap", but "get something working fast, and then
> build on it" :)
>

Sounds good to me :)  I'm still digging through the DBus docs, but in the
mean time I got something *really* basic working... it's just a download
results previewer. For now it lives at: git://
gitorious.org/quotebackend/quotebackend.git

To start with, I'm getting hung up on what's the best way to download stuff.
That code uses KIO Jobs, but, it just doesn't "feel right." I could very
well be doing something dumb. Maybe not initially, but eventually, I'd like
to be able to support parallel downloads as well as not lock-up/block
anything else. But I don't know how to do that..? Also, has there been a
firm decision either way on alkimia being strictly Qt? One alternative to
KIO I'm considering is QNetworkAccessManager and friends, as mentioned in
the Qt docs under Network Examples, but I haven't gotten the time yet to
play around with that stuff...

>
> In this particular case, I'd concentrate on getting the prices right,
> and any other data you can get "for free", and then you can build on
> it.
>

I'm a little confused by what you mean by "right." I'm taking it to mean the
price-algorithms are logically verified? Pretty much all the code I have
related to that stuff was literally the first C++ code I ever wrote, so
needless to say, it all needs to be rewritten. But this time I've been
through it once, so hopefully I learned at least a few lessons... :)  For
instance, storing the most recent close at index 0 makes life hella
easier... I still need to write the code to make sure, but, I think I at
least got the math all worked out and verified for the time conversion and
adjusted prices algorithms.

I think what I'm most uncomfortable with would be creating code not
controlled by a UI, so at least personally, I'm thinking my next step is to
split up that previewer UI from the 'core' into two programs, and get the
same functionality working over DBus. Any thoughts on that?

Also, is there any way I could maybe get a consensus on whether or not "the
powers that be" would ever allow TA-Lib to eventually be integrated into
this? The reason I ask is because it seems to me to determine whether I use
std arrays or QLists for storing prices. QLists are obviously more
convenient/less bookkeeping, but, they also don't work with TA-Lib. At least
not without copying all the data first, which I suppose isn't the end of the
world. Any strong opinions either way?


> Regards,
> Alvaro
> _______________________________________________
> Kde-finance-apps mailing list
> Kde-finance-apps at kde.org
> https://mail.kde.org/mailman/listinfo/kde-finance-apps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100525/33efca77/attachment.htm