welkum  tu  the  Kamibroke  divelupur  siet

introe:

Kamibroke will (hoepfully) be a dubll-entry ukownting proegram for yues with KDE.

just tu maek it kleer, this iz a baesik dubll-entry ukownting proegram, diziend tu be yuezd by wun pursun at a tiem. it iz not intendd tu be an ukownting sulueshn for enything but smorl biznis. the divelupur duz not klaem that it kumpliez with eny biznis ukownting standurdz.

I'v been sloely wurking on this sins mid .oktoebur, 2001.

at this staeg this proegram iz noewair neer yuezubl. if yue ar arftur a pursunull finanshll proegram then I rekumend yue try KMyMoney2.



downloedz:

Kamibroke proejekt-

downloed the proejekt yuezing CVS heer at .sorsforj. the kurunt vurshn in CVS iz ubowt 0.3.9. tu ritreev Kamibroke from CVS tiep in a turminll "cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/kamibroke checkout kamibroke" in the direktury yue wish tu downloed Kamibroke tu.

NB 1: the statistiks at .sorsforj for this proejekt ar inkurekt. at the sorsforj proejekt paeg it upeerz that thair iz no koed in CVS wen in fakt thair iz. if yue tiep in the ubuv cvs checkout kumand it will wurk.

NB 2: at this staeg Kamibroke iz intendd for yues oenly by divelupurz (at the moemunt that's just me) and peepll hue wish tu test vaireus parts ov the proegram. prezuntly Kamibroke duzn't du much, it iz not yuesful for enything. oenly downloed if yue wish tu test kumpieling and eksukyueting the koed wich haz been ritun so far!

NB 3: the downloed kuntaenz proejekt fielz for yues with KDevelop. it iz best tu yuez KDevelop for koeding and kumpieling Kamibroke.


udishnll jurnllz- (KPart kumpoenunt, opshnll downloed)


udishunll riports- (KPart kumpoenunt, opshnll downloed)



kumpieling and instulaeshn:

the yuezhuull 'konfigur, maek, maek instorl' shood wurk (noet: yue shood be ruet wen instorling).

noet: the instulaeshn mae not wurk propurly. if wen yue run the proegram it wornz that the daetubaes inturfaes loeding faelz or the menyuebar iz mising moest ov its ietumz then yue wil need tu manyueuly instorl the liebrureez, kamibroke.rc fiel, survistiep fielz, survisz and iekonz.


maeling list:

the Kamibroke maeling list iz heer at .sorsforj. if yue wish tu help divelup Kamibroke pleez joyn the list. orlsoe if yue fiend eny bugz pleez noetifie me on the list.
maeling list hoestd by: .sorsforj loegoe


kurunt foekus ov duvelupmunt:

sins 2007-06-01 - reeriet the implumentaeshn ov the KamibrokeView klas


fyuechur duvelupmunt


Kamibroke I (local single user, open-source, KDE-KPart based)

Milestone Planned New Features
green=done : yellow=in progress : red=yet-to-do : blue=yet-to-plan
Version
0.4.0
• implement - general database search in dbinterface1
• implement - user options to select the locale and the designated general journal
• implement - scheduling transactions
Version
0.4.4
• design and implement - asset register/inventory view and management
• design and implement - asset register/inventory database storage and access
Version
0.5.0
• design - kamibrokeĀ“s native file format (research existing standards/formats)
• implement - saving and loading data
• uncomment intro dialog, implement new book functionality and opening balances
Version
0.5.3
• port and improve - other cash payments journal (based on previous journal from kamibroke 0.2.9)
• port and improve - simple australian wages journal (based on previous journal from kamibroke 0.2.9)
• port and improve - other cash receipts journal (based on previous journal from kamibroke 0.2.9)
Version
0.5.4
• design and implement - cooperative journal data sharing
Version
0.6.0
• create - generic purchases journal
• create - generic purchases-return journal
• create - generic sales journal
• create - generic sales-return journal
Version
0.6.2
• create - generic accounts payable journal
• create - generic accounts receivable journal
Version
0.7.0
• implement - reports galore : have a look at what other accounting programs offer and copy them
Version
0.7.4
• implement - period end/closing balances
• implement - import/export pluggin filter architecture
Version
0.8.0
This is the first fully working version of Kamibroke!
• implement - database selection and configuration
• implement - database interface for atleast one of the GPLed databases
Version
0.8.0 -> 1.0.0
• bug fixes
• improvements - user feed back for improvements
• features - code user requested features




Kamibroke II (secure networked POLA multi-user, open-proof, capability based)

Milestone Planned New Features
green=done : yellow=in progress : red=yet-to-do : blue=yet-to-plan
Version
0.1.0
• wait - for a secure mirco-kernel 'open proof' capability based operating system (eg: Coyotos), device drivers, supporting standard libraries, windowing system and desktop environment to be developed : this will be years and years into the future.
• wait - for an object based language designed for use with networked capabilites and has constructs to assit automated software verification to be specified (eg: something like E with theorem proving constucts)
• wait - for a compiler and theorem prover for this language to be created
• design - a specification for Kamibroke (ie: a networked, multi-user, fine-grained security double-entry accounting program) that runs on this platform. This specification should include guarantees about the security and logical correctness of Kamibroke: eg. It should-
• Guarantee that the component journals/reports/etc. are confined and that the communications between the components internally on a machine and externally over a network are secure and occur only through authorised channels/interfaces.

WARNING: Rant follows- :)
Confinement is the reason why this cannot be based on KDE/KParts. I donot know any way to confine an installed part, I believe that it is actually impossible to do. Whenever you install a part on KDE, the part runs with full authority of the main application. It becomes 'part' of the main app. This means that an installed part cannot be stopped from accessing any system service that the main app can access. Ie: An installed part can access all the local files, internet addresses, memory addresses, hardware, etc. that the app can. Hence it is impossible to prevent the part from sharing its data with other installed parts. This means that the fine-grained POLA (Principle Of Least Authority) security scheme that I would like to have cannot be implemented.
Incidentally an application itself cannot be easily confined and still be useful on standard-linux/Windows/or any other main stream OS. Generally, programs on these systems run with the privileges of the user who owns them. This is almost always grossly excessive authority. Take for example, any text editor: when you command it to save a file, what you are really doing is asking 'Please program, out of all the files that you can modify,'- which would normally be most data files in the user's account- 'please modify the one named x...x.txt'. Whereas on a system that uses capabilities (such as Coyotos) when you ask the program to modify a file, what you are doing is giving it authority to modify that particular file and no others. So if, before you asked it, it had not be given any file modifying authorities, then the only file that it can change is the file named x...x.txt. One way to achieve confinement on traditional systems is to completely isolate the program from all others. This might work for a simple program such as a plain text editor, but for programs that are required to work cooperatively with other programs (such as programs that support Drag'n'Drop) this renders that program useless.
An interesting side-effect of this is that if using capabilites, when serializing the data it does not have to be encrypted. The only reason why data is currently encrypted in accounting applications is because other programs (such as the text editor above) can access it. (PS: I not saying that data exchange over the network doesn't need encryption. Packets sent over the network would still need to be encrypted like normal.)

• Guarantee that the basic principles of double-entry accounting are observed by any installed component parts (eg: each new transaction created by a journal is balanced and occurs within the current accounting period; each new account is a descendant of one of the five major account types) otherwise the part is forbidden to do any processing on the database.
• Provide a security scheme that controls user authority. The scheme should allow authorities to be granted according to the POLA (Privilege of Least Authroity) principle. eg: Within a multi-department store, a junior sales assitant should only be able to make/edit sales/sales-return transactions within their department (with maximum amount restrictions) and not be able to do anything else. An accounts-payable clerk should be able to settle accounts due but not be able to create/edit/view any sales and not be able to create/edit new purchases. Whereas the company accountant should be able to view any transaction but only able to create end-of-financial-year transactions and special evaluation/adjustment transactions (eg:depreciation, goodwill). Lastly, a company director should be able to view any transaction but not be able to create/edit any.
A networked, object capability based architecture facilitates reasoning about these issues.

Version
0.1.0 -> 0.8.0
• implement - 'open proof' Kamibroke II according the specification.
Version
0.8.0 -> 1.0.0
• improvements - user feed back for improvements
• features - code user requested features



skreenshots:

Kamibroke in akshn: Kamibroke's skreenshots

individzhuull jurnuls:
simpl waegz jurnul
uthur kash paemunts
uthur kash riseets

individzhueull riports
---