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

[Thomas Baumgart]

On Tuesday 25 May 2010 12:30:20 Brian Cappello wrote:

[...]

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

What you need to look into is called asynchronous transfers. I am pretty sure 
that KIO supports them but don't know about QNetworkAccessManager and Co.

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

As a backend functionality I suppose we should stick with Qt. Maybe, a layer 
of abstraction can handle that such that on a KDE system you use the KIO 
interface and on a non-KDE system you use the QNetworkAccessManager based 
backend. Determination which one to use should happen at runtime. But maybe 
that is something for a second step and the first sticks with KDE.

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

Well, in this case I consider myself as part of "the powers that be". We do 
these integrational things in KMyMoney with other libraries as well (e.g. 
LibOFX, AqBanking) and try to keep the modules that access them as plugins to 
the main application. This allows to build the software even if parts are not 
available. Of course, if some did not have TA-Lib installed, he/she would not 
be able to build alkimia with the support of your functions.

License wise I don't see a problem to use TA-Lib. AFAICT it uses the New or 
modified-BSD license (http://en.wikipedia.org/wiki/BSD_license) which is 
compatible to GPL as per 
http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses#Approvals .

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
'I used *that other operating system* (now to be considered
open source? <g>) for some years' - anonymous source
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100525/66f587af/attachment.sig