[Kde-finance-apps] Re: Fwd: Season of KDE status check

[Klaas Freitag]

Am Mittwoch, 25. Mai 2011, 19:31:04 schrieb Thomas Baumgart:
Hi,

> > Thats true. The ID generator has to be in the DBus backend, as various
> > apps could generate a transaction and still the ID needs to be unique.
> > However, on the mobile device, there is no connection to the service on
> > the bus, so the mobile entry can only be unique in the mobile device. So
> > the data should contain a "local ID" (assigned in the mobile) and a
> > 'really' global unique ID assigned by Alkimia at sync time. That,
> > however, is only true if we want continous IDs. If not, we could create
> > real unique ids if we combine for example the netcard MAC ID with a
> > timestamp and calc an MD5 from it. That results in a worldwide unique ID
> > and can be done locally easily.
> 
> Sorry, but I have to object here. The source of the transaction (in this
> case the mobile device) *must* assign the unique ID.
Ok, so thats the way where the IDs are not continuous.

> See http://linux.die.net/man/3/libuuid for example. Use existing stuff and
> don't reinvent the wheel.
Sure, I wasn't aware of. And even better, there is a Qt implmentation as well:
http://doc.trolltech.com/4.6/quuid.html

> > 
> > Can these file formats also store the status such as "Money expected but
> > not yet there" for example which are needed for example for the Kraft
> > usecase (You remember: Invoice sent, money expected) ?
> 
> Why would I want to trigger such a transaction from a mobile device? 
Haven't heard about Kraft Mobile yet ;-) ? its not yet existing, but why not?
Honestly I think there is no difference between mobile and not mobile in this 
regard, isn't a non mobile nothing else than a currently connected mobile?

> It
> should be generated by the application that prints the invoice. During the
> last (or better first) finance sprint I tried to explain, that this status
> is handled by transaction towards a specific account. There is no need for
> such a flag.
Ok, but that means that the account information has to be in the Alkimia data
base, and apps like Kraft have to have knowledge about the meaning of the 
different accounts. I see. 
> 
> A glossar is probably not enough - though helpful. And on top, we do have
> one on http://techbase.kde.org/Projects/KdeFinanceGlossary
Cool.
> 
> We all need some basic understanding of accounting practices.  Maybe an
> idea to get together during akademy for it.
Thats great. Would you offer a BOF about that and teach us?

Klaas