[Kde-finance-apps] Defining the scope of the work during Season of KDE - Alkimia DBus service

[Alvaro Soliverez]

Hello,
see my comments below.

On Mon, May 17, 2010 at 10:04 AM, Klaas Freitag <freitag at kde.org> wrote:
> Am Samstag 15 Mai 2010 05:12:01 schrieb Alvaro Soliverez:
> Hiho,
>
>> this mail is to help define a clear scope for the work, in order to
>> setup a schedule that can work for all of us.
> Cool, thanks Alvaro for pushing and hello to Mukesh :) Nice to have
> you working on that!
>
>> Now, we should define more accurately what we expect.
>>
>> Oveview:
>> Alkimia is going to be a DBus service that will receive and store
>> financial information. Most of that information is going to be about
>> transactions (people paying you money, or you paying other people
>> money, stock quotes, etc.)
>> The final product will have many different services, so to kickstart
>> that effort we decided to build a prototype with 2 simple services.
>
>> The first service will receive transaction information:
>> - Source application
> Application id - an per application unique ID
>> - Date
> What about a due date?
>
>> - Category or classification of the transaction (music, grocery, salary, etc.)
>> - Memo
>> - Amount
> As a return value, I would hope for a Alkimia-ID which identifies the
> alkimia record globally, well, nearly globally ;-)
>
>>
>> The second service will allow a financial application to retrieve the
>> info of the transactions received by Alkimia. Specifically, it should
>> only inform those new transactions since the last time it queried
>> Alkimia. The fields should be those very same.
> The status of a transaction should also be queriable by alkimia-ID, and
> if possible by a application/app-id tuple.
>
>> Alkimia should store the data either in SQLite or Akonadi, and it
>> should have an event log.
>>
>> The amount field might get tricky, because representing money is
>> usually a problem. We have a class in KMyMoney that we can use for
>> that purpose. Renaming it and slashing some KMM-specific functionality
>> should be no problem.
> ACK
>> It's basically to double put together, so
>> storing in a database should be no problem either.
> I don't really understand that sentence ;-)

My mistake, I mean "2 double variables put together"

>
>>
>> Klaas, am I forgetting something?
> Not that I am aware of now. I was thinking about a status of a transaction
> such as money outgoing, money incoming, money expected, but AFAIR that is
> done by the different categories, right? I do not really remember that.
> Alvaro, can you explain that?
>

Yes, the transaction should have a status. I think the sum of the
transactions should be done by the applications, not by Alkimia, at
least for now.


> BTW - I think we should use the mailinglist kde-finance-apps for this kind
> of discussions. I am sure the others have input on that as well and we
> should pick that up :-)

You are right. Sending to the list.

>
>> Mukesh, feel free to ask anything you might feel is not clear enough.
> Sure, poke us and have a lot of fun,
>

Regards,
Alvaro