On Friday 22 July 2005 2:33 am, Chris Shoemaker wrote: > > I think it's risky to offer option 2 without some kind of fallback - what > > if the server is actually local and the problem is a sign of something > > more serious - the user's system has become unstable etc.? Alternatively, > > the user might just need to do something else and cannot keep GnuCash > > running until the server comes back online. > > That doesn't sound very good.
? The user has to make that decision. If the backend is designed to go on and offline then the QofBackend can deal with that. This would only come into play when the user expects a save/commit and an error is reported. As an option in that error dialog, the user needs some way of saving the changes they have made so far - in case it IS a major fault with the server. GnuCash cannot always detect that, neither can QOF, only the user has that information. > You're describing the worst-case scenario. Going offline is not > necessarily an error condition. Yes, I'm only concerned with the error condition - a complete failure in the connection. Everything else is backend-specific because only certain backends can ever support incremental backups, partial data or remote connections. > Many frontend/backend systems are > *designed* to do this as a regular part of operation. For those > systems, the solutions you describe are not acceptable. Those would not report an error, they are designed to operate that way. If the backend repeatedly fails to communicate with it's own server, it will have to report an error eventually and this fallback would be available. The backend mechanism is generic - it has to deal with each backend equally and let the backend do what it can do best. > It may be > impossible to save everything to a local file, because client may have > only the portion of the data that he was editing/viewing. Then the book is a partial book and can be saved to QSF. The user cannot be left dangling with no way to recover data entered after a remote connection went down. > And how often would we resend the entire collection of splits? Only in case of a resumption after an error condition and only under direct user control. > > > 4) We do a tree search that finds that only one Account is marked as > > > "contains dirty Splits" so our linear search through Splits is only > > > through that Account's Splits instead of all Splits. We find the > > > changes and commit them. > > > > To me, this is doing the work of the backend in the UI. A backend that is customised to handle incremental backups and partial data will be able to identify the modified instances using last_update without EVER knowing anything about this "tree" that simply doesn't exist. There is NO tree. (I wish I'd said that the first time you mentioned it - note to self, do as Derek advised and NEVER allow any use of "tree" again!) > > Remember, the > > backend > > You're saying the frontend doesn't need to know which instances are dirty? ? No, I'm saying that the backend can do it's own thing, including on and off cycles if it supports those. The backend does not understand an Account. It has no concept of a Split. They are all just objects. The backend cannot do a tree search, no tree exists. As I showed in the previous message, the source code HAS no tree - it only exists in the human mind, the UI and the docs. There is NO direct relationship between an Account and it's Transactions. None. Zip. No engine call can go from an Account to a Transaction, the source code is simply not built to support that, neither does it need to. Accounts know about their Splits and Splits know about Transactions and Accounts. Transactions know nothing of Accounts and Accounts know nothing about Transactions. The engine knows NONE of this. All the engine cares is that there are three objects and N parameters. What the engine doesn't know, the backend cannot understand and the book cannot find. That is why QOF can be spun-out as a generic framework, it has had all the financial objects, all the human concepts and all the specific relationships stripped out. It treats every entity the same way, everything is equal, no hierarchy exists of any kind. In some ways, I regret using the term book - it implies a structure with a cover, a table of contents, an index, chapters and page numbers that simply does not exist. In reality, it's closer to a tombola: lots of coloured balls with numbers stamped on them, each one identical to all the others in all other respects. Balls of the same colour are attached to each other (collections) which is where the analogy breaks down. > Well, the functions in the engine know that an Account has a list of > splits. No, they do not. The engine code does not know anything called an Account or a Split. All it knows is that one object contains a pointer to another object using a parameter identified using a particular static string. Some parameters are strings, or integers or booleans etc. Until v.recently, no object contained a list of anything, as far as the engine was concerned - there was no parameter that could express a list of other objects. At no point does the engine have any concept of a Split or an Account or any other human concept. It's all just objects and parameters. That's it. > > The tree is too specific - QOF is generic and does not get into the > > specific conceptual relationships. > > In your view, where exactly are those relationships best represented? 1. The UI display 2. The docs 3. The minds of the developer and the user. There is no place for specific conceptual relationships in the engine, the backend, the book or the session. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpdD04fhgpzg.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
