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

[Thomas Baumgart]

Hi,

on Thursday 26 May 2011 08:06:41 Klaas Freitag wrote:

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

They don't need to be continuous. They need to be (globally) unique, that's 
all.

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

I know, but since Salim is not using Qt I did not mention it.

> > > 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 depends on the implementation, but in general that's what it is.

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

Kraft needs to be configured up front to know about accounts. That will be 
done through an Alkimia service that interrogates the underlying accounting 
app (somehow I envision it that way). This service must be provided by apps 
like KMyMoney or Skrooge. I don't see right now a case, where Kraft can use 
something w/o knowledge about the underlying accounting app.

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

I can certainly do that, but I don't know today, if I will make it to Berlin 
and when that will be (I currently have a no-go for the weekend and can arrive 
Monday at the earliest and can't stay the whole week).


-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
Hexdump should be compulsory at kindergarten! -- Jos van den Oever
Found on http://www.kdedevelopers.org/node/3569
-------------------------------------------------------------
-------------- 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/20110526/30dec53b/attachment.sig