guile & i18n
I have implemented a new way of using gettext from scheme files that is easier to use than the string databases that are currently used in, for example, the reports. Essentially, it works the same way as in C. To mark a string as translatable and load the translation at the same time, use the '_' function: (display (_ "Hello, World")) ;; print the appropriate translation ;; of "Hello, World" To makr a string as translatable without loading the translatable, use the 'N_' function: (define hello (N_ "Hello, World")) ;; mark "Hello, World" as ;; a translatable string ;; hello == "Hello, World" (display (_ hello));; print the appropriate ;; translation of "Hello, World" The strings will be automatically collect statically during the build process. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
On 20-Dec-2000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I beleive the above architecture renders the whole previous > discussion moot. I also think its a very, very exciting thing to do. > It solves a number of technical issues, such as multi-user, that > have been plaguing us. Next, it give us world-class financial ASP > capabilites. Finally, I think this is what microsoft is thinking > about when it talks .net and this alone makes it important for us > to do this more/better/faster. I think this approach is very interesting... I've been looking at the way these kinds of technologies have been changing lately and I've noticed three things I think are really cool: 1. XML/SOAP (what Microsoft is calling "web services") to provide distributed RPC like services. This does much the same job as CORBA, but uses technologies that can be re-used elsewhere easily, and so have a low maintenance cost and a produce a lot of synergy (HTTP and XML). This can also take out a *lot* of the nastiness of cgi-bin, since you can just often just request information you want as if you were making a normal function call (well, ok, perhaps a bit more trouble). 2. XML/HTML with special embedded that rely on a particular "plugin" to provide rich functionality. This is a bit like how Flash animations or things like that work. The neat new thing about 2 is that it is increasingly being used in an inside-out manner, with the web browser being embedded inside an application, and the application provides the semantics of the tags. Of course multiple "applications" can interact to provide semantics (e.g. gnucash register and guppi). Even if you aren't using any external content, the XML/HTML is being used to control the GUI rendering. 3. Server-side "dumbing-down" of 2 to provide an acceptable interface for dumb clients. For example the GUI widgets in Microsoft's .NET WebForms libraries can be: (a) downloaded as bytecode to run on .NET runtime, user value changes are sent to the server using XML/SOAP callbacks (b) converted to a known set supported by IE 5.5, which turns them into neat graphical widgets using lots of JScript, sending results back using some sort of hackery I never really investigated (c) turned into standard HTML which Netscape can display, returning results with a standard form. Since 2 was just XML anyway, this is really just a transformation of XML -> XML or HTML. Note that when you do this, you usually have to make a translation of any XML/SOAP calls you might want to make into cgi-bin calls. E.g. add links to the account names, which will generate a new page that gives a summary of that account. In a rich client you might retrieve the summary yourself using SOAP/XML, and not even worry about loading the rest of the page. Anyway, I'm sure some of you have seen this stuff already, but I see a lot of potential in using this kind of technology. And yes, it is almost exactly what Microsoft mean when they talk about .NET (although they also throw in a virtual machine for good measure). XML/HTML is used to unify presentation. Applications are extensions of the unified presentation technologies. XML/HTTP/SOAP is used to unify distributed method calls and data transfer. Services are extensions of data transfer technologies -- providing content is one kind of service, but there are others (authentication, backup, synchronization, etc). -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. [EMAIL PROTECTED]# http://www.cs.mu.oz.au/~trd # ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
On Wed, Dec 20, 2000 at 11:03:13PM -0800, Dave Peticolas wrote: > "Phillip Shelton" writes: > > > > ACCOUNT > > --- > > account_guidchar32 > > parent_account_guid char32 -> account.account_guid > > group_guid char32 -> account_group.group_guid > > account_typeinteger -> > > account_types.acct_type_code > > account_codechar20 a mnemonic for the user > > account_nametextbank, lienholder, etc. > > description textlong explanation of the > > account > > commodity_guid char32 -> > > commodities.commodity_guid > > balance rational > > cleared_balance rational > > reconciled_balance rational > > share_balance rational > > share_cleared_balance rational > > share_reconciled_balancerational > > commodity_scu integer smallest convertible unit > > > > kvp_data??? > > > > > > > > should there be a smallest convertible unit for the security(damount) as > > well as for the commodity? Or do only splits have securities? > > You're right, there should be one for both. I'm trying to come up with a way to not require both of those fields. Very possibly I will be unable to, but we'll see. :-) -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor & Coordinatorhttp://www.linuxdoc.org Finger me for my public key Mine is the ecstasy of the spirit And Mine also is joy on earth. For My law is love unto all beings. -- from The Charge of the Goddess, Doreen Valiente ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
On Wed, Dec 20, 2000 at 08:55:34PM -0600, [EMAIL PROTECTED] wrote: > > OK, here's the dope: > > I don't think rob is entirely aware of the possibilities that his XML > file format opens up. Some of the readers of this mailing list may > also not be aware of what demos grib has done with embedding guppi > in html. I don't know how many people are aware that the cvs branch > of gnucash has a web browser more-or-less built into it. Its not a > great all-purpose browser, but for the following example, that don't > matter. > > GnuCash is just inches away from being a financial ASP website. > Here's how: > > Imagine logging into a special ssl-protected website. (using > gnucash's built-in browser). You've authenticated, and now you want > to look at your stocks. You are taken to the following web page: [S-n-n-n-n-n-i-p!] > I beleive the above architecture renders the whole previous > discussion moot. I also think its a very, very exciting thing to do. > It solves a number of technical issues, such as multi-user, that > have been plaguing us. Next, it give us world-class financial ASP > capabilites. Finally, I think this is what microsoft is thinking > about when it talks .net and this alone makes it important for us > to do this more/better/faster. Yeah, baby, yeah! I'll also mention that psql spits out its tables in customizable html, and can be run via cgi scripts. You can write shell scripts or perl scripts to execute queries and retrieve the results in html tables. Maybe this is the way to go and maybe not, but it is interesting enough to investigate, especially if we adopt Linas' proposal. Which I like. A lot. Can you tell? -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor & Coordinatorhttp://www.linuxdoc.org Finger me for my public key Hoof and Horn, Hoof and Horn All that dies shall be reborn ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
db build scripts
I am now building tables in pg and I've made the build scripts available at http://www.lupercalia.net/createschema.sql. The table schema in the design doc are out of date slightly, and will become more so. I am leaving them there for the time being so I can make notes and refer to them to see why I did something the way I did. I expect to have these ready to go into cvs in a week or so. Then anybody else who wants to help me can join in the fun. -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor & Coordinatorhttp://www.linuxdoc.org Finger me for my public key -- Hoof and Horn, Hoof and Horn All that dies shall be reborn ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
On Wed, Dec 20, 2000 at 08:55:34PM -0600, [EMAIL PROTECTED] wrote: > > OK, here's the dope: > > I don't think rob is entirely aware of the possibilities that his XML > file format opens up. Some of the readers of this mailing list may > also not be aware of what demos grib has done with embedding guppi > in html. I don't know how many people are aware that the cvs branch > of gnucash has a web browser more-or-less built into it. Its not a > great all-purpose browser, but for the following example, that don't > matter. > > GnuCash is just inches away from being a financial ASP website. > Here's how: > > I beleive the above architecture renders the whole previous > discussion moot. I also think its a very, very exciting thing to do. > It solves a number of technical issues, such as multi-user, that > have been plaguing us. Next, it give us world-class financial ASP > capabilites. Finally, I think this is what microsoft is thinking > about when it talks .net and this alone makes it important for us > to do this more/better/faster. Does this mean you are envisioning a server which can handle more than one set of accounts and more than one set of transactions? -- Let there be beauty and strength, Power and compassion, Honor and humility, Mirth and reverence within you. -- from The Charge of the Goddess, Doreen Valiente ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: guile & i18n
On Thu, Dec 21, 2000 at 12:59:58AM -0800, Dave Peticolas wrote: > (display (_ "Hello, World")) ;; print the appropriate translation > ;; of "Hello, World" Thanks Dave! you're a god. b.g. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
[EMAIL PROTECTED] wrote: > > OK, here's the dope: > > I don't think rob is entirely aware of the possibilities that his XML > file format opens up. Some of the readers of this mailing list may > also not be aware of what demos grib has done with embedding guppi > in html. I don't know how many people are aware that the cvs branch > of gnucash has a web browser more-or-less built into it. Its not a > great all-purpose browser, but for the following example, that don't > matter. > > GnuCash is just inches away from being a financial ASP website. > Here's how: In short - Wow ! I like it. > -- We've side-stepped the sql transport issue, sort-of. All data >between gnucash-the-web-browser and gnc-the-apache-server is in >the form of this oddly marked-up html with embedded, uuencoded >gnc-xml. On the server side, we have to write some cgi-bins >that yank data from any old sql db, and convert it into gnc-xml. >(personally, I recommed using gnc-engine to implement those >cgi-bins). As the one area I'm competent to comment on (databases), this makes perfect sense to me. -- Pat -- This message does not represent the policies or positions of the Mayo Foundation or its subsidiaries. Patrick Spinler email: [EMAIL PROTECTED] Mayo Foundation phone: 507/284-9485 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
<[EMAIL PROTECTED]> writes: > Lets reanalyse the requirements. You want security. Why? to run over > the open internet? If you're running over the open internet, then Not exactly. It's just that I don't trust the network I'm sitting on, regardless of where I am. Let's suffice it to say that there ain't no such thing as a "trusted network." The whole concept is flawed. Let me explain what I mean. The whole concept of a trusted network assumes that you can trust everyone who has access to that network. It also assumes that you trust every machine sitting on that network. It also assumes that you trust the people running the network. It also assumes that none of your machines can be turned against you. It also assumes that none of these assumptions can be broken. So, you're sitting at home on your home LAN. Let's assume you're connected to the internet via DSL or CableModem. Do you know how your ISP has you configured? Are you absolutely sure you're not bridged? I have some friends who were able to see their neighbors' traffic across their cablemodem, so it certainly is possible. Would you trust your neighbor to know your financial situation? Also, how secure is your home machine? Are you sure nobody broke in and installed a sniffer on your (trusted) home network? Hey, somebody broke into _my_ Linux box a year ago, so don't quaff that it can't happen to you :) Let's take a small business example... Remember that financial information is considered extremely private. There are even special laws for protecting it! Indeed, even when the United States had export limits on cryptography, there were specific exceptions for financial data. If you could prove that your system was just for financial data, you could export strong cryptography, even when everyone else was limited to less-than-DES. So, do you trust all your employees and co-workers? How do you know what the employee in the next office is doing or thinking? Are they disgruntled? Maybe they want to know how much you're making? Perhaps they are being paid by a competitor? Do you trust the people actually running the network? Who maintains your routers? Of course, don't forget about those pesky crackers, who may be paid to break in and get your financial information. All it takes is a single unprotected windows box and they now have all your network traffic from your supposedly "trusted" network. Obviously we still have to trust SOME people, such as the users who need to access your financial data, and potentially the sysadmins and DBAs who maintain your database. But you can reasonably limit that to a finite number of people, rather than everyone. And yes, just using SSL would protect you from the casual snooper.. Except how do you prime the system? How do you get your passwords into the database? Are you sure your sysadmins use SSH all the time? And how do you know that your SSH wasn't attacked (there was an active man-in-the-middle attack against SSH at the IETF last week, and yes, a number of people were actually hit by this!) The worst thing you can do is claim that someone else will provide you your security and privacy. If you still have doubts or concerns, I can recommend some books or courses on basic network security. The reality is that it's scary out there, so we should be proactive in protecting our "customers" and their data. > If there are no public servers, then wouldn't encryption be better > provided by a VPN or other tunneling mechanism? Why reinvent? See above. A VPN provides you security across the core public network, but it doesn't protect you from insiders. Unfortunately, most financial trouble is caused from insiders. I'm not proposing that we re-invent, at least any more than we would have to anyways. We'd still have to invent the SQL queries, XML Schema, CORBA interfaces, etc. Indeed, my first approach would investigate using ONC RPC as the marshalling system, which is much less overhead than CORBA, IMHO, but would require the about same amount of work. Also, ONC RPC (aka SunRPC) is distributed on just about every UNIX platform (I can't think of any platforms that DON'T have ONC RPC available) so we wont have to worry about portability. I've just grabbed a book on CORBA, and I'm looking at information on ORBit. I've certainly not bought into to one camp or another. > > I've also volunteered to write the gnc_server/gnc_client code, > > I suppose I shouldn't discourage, then. :) > > provided I am given help with providing the APIs that the engine will > > need. > > Hmmm. That's hard. Actually, it's not that hard. We've been working towards this on the list. For example, we've been discussing the Query API, which is one such data-store API. We would still need to discuss the APIs to obtain the lists of accounts, groups, etc. And we also need to discuss the data write APIs, and data cache conherency (events & notifications?) I think as we discuss APIs this will "fall out" a
Re: client-server
This is an interesting approach, but HTTP is _SLOW_. You have to setup and teardown a TCP connection for each request, and you have to build an SSL association for each request. This just takes time. Not only that, but forking off a CGI is also very expensive. Having all of the network connection setup cached through a whole session (rather than per request) will save a lot of time, but I don't know if we can do that easily with HTTP or Apache. I suppose we could build Java Servlets to solve the cgi forking problem, but then we'd need to port GnuCash to Java. Or we could build an Apache module (mod_gnc?). I think this is a wonderful approach for report generation, but I'm not convinced it's the best approach for day-to-day data entry. -derek <[EMAIL PROTECTED]> writes: > OK, here's the dope: > > I don't think rob is entirely aware of the possibilities that his XML > file format opens up. Some of the readers of this mailing list may > also not be aware of what demos grib has done with embedding guppi > in html. I don't know how many people are aware that the cvs branch > of gnucash has a web browser more-or-less built into it. Its not a > great all-purpose browser, but for the following example, that don't > matter. > > GnuCash is just inches away from being a financial ASP website. > Here's how: > > Imagine logging into a special ssl-protected website. (using > gnucash's built-in browser). You've authenticated, and now you want > to look at your stocks. You are taken to the following web page: > > -- > > > > Your Portfolio! > Based on the current market values, your asset allocation graph is > shown below! Just click and drag on this live guppi pie chart! > The left mouse button lets you move pie slices around, and the > right button lets you rotate the whole pie. > > > > > > > value="100 200 400 800 1600 3200"> > value="teeny tiny small medium large huge"> > value="red blue orange green purple goldenrod"> > > > > > > > > > -- > What did this web page do? First, it instructed gnucash to use a > live guppi chart do display data. The above is a direct cut-n-paste > of some code that bill dropped into cvs recently. (Yes, the next > version of gnucash will have graphs). > > Next, this web page sent us some gnucash data. (it might be better > to compress it, uuencode it, and send it under a separete mime-type, > but lets gloss that one). The sample data is a cut-n-paste out > of the gnucash cvs tree, some sample files in the new file format. > > What have we accomplished here? > -- we've built a web site that only gnucash can look at and make >sense of. > > -- we've built a finacial website whose performance blows the doors >off yahoo.com or fncentral.com Basically, no nasty html forms >needed. We've got a slick ledger. We've got interactive graphs. >Microsoft .net, take that! Pow! Bang! > > -- We've solved the multi-user login issue. Sort of. At least, we >turned the multi-user login issue into a standard web/apache >login issue, and there's mod_htpasswd and fancier, mod_kerberos, >to deal with that. And, since this is just plain-old apache, >we're using plain-old mod_ssl to encrypt for transport. > > -- We've side-stepped the sql transport issue, sort-of. All data >between gnucash-the-web-browser and gnc-the-apache-server is in >the form of this oddly marked-up html with embedded, uuencoded >gnc-xml. On the server side, we have to write some cgi-bins >that yank data from any old sql db, and convert it into gnc-xml. >(personally, I recommed using gnc-engine to implement those >cgi-bins). > > > I beleive the above architecture renders the whole previous > discussion moot. I also think its a very, very exciting thing to do. > It solves a number of technical issues, such as multi-user, that > have been plaguing us. Next, it give us world-class financial ASP > capabilites. Finally, I think this is what microsoft is thinking > about when it talks .net and this alone makes it important for us > to do this more/better/faster. > > > --linas > > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
On Thu, Dec 21, 2000 at 01:13:02PM -0500, Derek Atkins wrote: > <[EMAIL PROTECTED]> writes: > > > Lets reanalyse the requirements. You want security. Why? to run over > > the open internet? If you're running over the open internet, then > > Not exactly. It's just that I don't trust the network I'm sitting on, > regardless of where I am. Let's suffice it to say that there ain't no > such thing as a "trusted network." The whole concept is flawed. Let me > explain what I mean. You're not paranoid, they really are out to get you. Seriously, though, you're right about the strong security requirements. We cannot possibly be too careful. Trust nobody. > I think as we discuss APIs this will "fall out" as we try to abstract > out the data store. This will all be necessary if we modularlize the > SQL code anyways. So we should get a lot of this discussion for free, > provided that we do limit the scope of where SQL enters the rest of > GnuCash. I think the SQL code should not be marshalled over the wire. Keep SQL on the server side entirely. -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor & Coordinatorhttp://www.linuxdoc.org Finger me for my public key Corn and Grain, Corn and Grain All that falls shall rise again ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
On 21 Dec 2000, Derek Atkins wrote: [much scary yet true stuff about network security] > I've just grabbed a book on CORBA, and I'm looking at information on > ORBit. I've certainly not bought into to one camp or another. "Distributed Objects Survival Guide", although it looks like a stupid "CORBA and COM+ for dummies" type of book at first sight, is actually quite usefully objective, deep, and covers the implication of everything. ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
David Merrill <[EMAIL PROTECTED]> writes: > I think the SQL code should not be marshalled over the wire. Keep SQL > on the server side entirely. Oh, I agree. I would rather marshall requests in a more GnuCash-centric manner (e.g., the Query API) and marshall GnuCash Objects (e.g. Splits, Accounts) directly back. This implies a GnuCash marshalling system (which is really built on something like RPC/CORBA/etc but has the GnuCash object definitions), but I believe this is the right approach. I'm sure others disagree ;) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
On Thu, Dec 21, 2000 at 02:03:13PM -0500, Derek Atkins wrote: > David Merrill <[EMAIL PROTECTED]> writes: > > > I think the SQL code should not be marshalled over the wire. Keep SQL > > on the server side entirely. > > Oh, I agree. I would rather marshall requests in a more > GnuCash-centric manner (e.g., the Query API) and marshall GnuCash > Objects (e.g. Splits, Accounts) directly back. This implies a GnuCash > marshalling system (which is really built on something like > RPC/CORBA/etc but has the GnuCash object definitions), but I > believe this is the right approach. Is it possible that the answer is to take the existing engine code and separate the Query API into calls into a corresponding API on the server side? I'm still getting familiar with the code, so I have only a vague concept of its functions. But obviously the existing Query API is working. -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor & Coordinatorhttp://www.linuxdoc.org Finger me for my public key Let My worship be in the heart that rejoices, For behold-- All acts of love and pleasure are My rituals. -- from The Charge of the Goddess, Doreen Valiente ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
It's been rumoured that David Merrill said: > I'll also mention that psql spits out its tables in customizable html, > and can be run via cgi scripts. You can write shell scripts or perl > scripts to execute queries and retrieve the results in html tables. This is of course a possiblity, but the simplest thing to do would be to use libgnc_engine.so, as it stands today, ause it to create a cgi-bin, and use its xml-file-io capabilites to push the data to stdout. > Which I like. Thanks. Of course, we still need to have libgnc_engine talk to an sql database, and still need to slove the caching problems, and a bunch of other issues. But I think a cheapo demo could be done really quick (a few days/weeks) by someone who knows apache & cgi-bin, and cares to learn about libgnc_engine and its api. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
It's been rumoured that Derek Atkins said: > > This is an interesting approach, but HTTP is _SLOW_. You have to ahh, what are you envisioning? a thousand hits a second? www.linas.org serves up 20K pages a day, and serves up cvs.gnucash.org, and its a 7 year old 486 whose load average stays under 0.1 (and uptime would be years, if our power company were reliable...) > setup and teardown a TCP connection for each request, and you have to http/1.1 uses sopcket keepalive aka persistant connections by default. netscape 3.0 and i.e. 2.0 and newer ask for keepalive by default. > build an SSL association for each request. ssl *is* slow. But a pentium-166 can still push out several hundred ssl encrypted web pages a second, I beleive. > only that, but forking off a CGI is also very expensive. again, on an old pentium, you can fork off thousands of cgi-bins a second. This stuff starts to matter only when you start hosting at exodus communications. > Having all of the network connection setup cached through a whole > session (rather than per request) will save a lot of time, but I don't Socket keepalive is inside of apache (in fact, any modern webserver). There are also SSL sessions, which are used to avoid public-key renegotiations. I beleive SSLv3 sessions last an twenty minutes by default, and after that, a secret-key renegotiation is forced (to avoid snooping & replay attacks). The timeout is configurable. I've never used apache's mod_ssl, but I would guess all the config paramters for ssl sessions timeouts are there. > build Java Servlets to solve the cgi forking problem, but then we'd Hah! If you think cgi-bins are slow, then you've never used java servlets. Servlets are about an order of magnitude slower than cgi-bins, and it pretty much goes downhill from there. Java and perl have similar performance, and as often as not, perl is faster. Remeber. perl has JIT bytecode too. Never mind that Java can't deal with 24x7 environments. Having personal scars from debugging jvm mem leaks crashes & hangs in a netscape enterprise & websphere environment, I conclude Java is for chumps. > I think this is a wonderful approach for report generation, but I'm > not convinced it's the best approach for day-to-day data entry. No, but that's the whole point: because most of the data is cached locally in the gnucash client, responsiveness is excellent. Furthermore, if you are running your gnucash server/cgi-bins on a local, ether-net connected web server, the perceived responsiveness (as perceived by user) should be around a tenth of a second, about the same as it would be for a raw socket, corba, or sql or other client-server desing.The most likely slowest part of the system will be the display and graphical layout on the client side. --linas Oh, and Merry Christmas!! ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
Hi Derek, I want to say up front that I'm enjoying this conversation. I say this because my response may seem like flame bait at times. So please don't interpret any terseness or stridency below as an attack. --linas It's been rumoured that Derek Atkins said: > > <[EMAIL PROTECTED]> writes: > > > Lets reanalyse the requirements. You want security. Why? to run over > > the open internet? If you're running over the open internet, then > > The whole concept of a trusted network assumes that you can trust > everyone who has access to that network. It also assumes that you > trust every machine sitting on that network. It also assumes that you > trust the people running the network. It also assumes that none of > your machines can be turned against you. It also assumes that none of > these assumptions can be broken. This is indeed the standard definition of a trusted network. > So, you're sitting at home on your home LAN. Let's assume you're > connected to the internet via DSL or CableModem. DSL/cable modem is not a trusted network. Its open network. Yes, the kid down the block is probably snooping your packets. > Also, how secure is your home machine? If your home machine is 0wn3d, then you can't trust it, and no amount of encryption can fix that, period. If your 0wn3d, hacker can write a linux kernel extension to grab whatever data from wherever, and that's that, and yes, there have been cases of 'wild' kernel extensions (beleived to actually be authored by nsa, but that's another story...). > Let's take a small business example... Normally, a machine with finacial data, esp. in a business, should not be connected to the net, period. I'm sure there are mom&pop business that violate this. There are ecommerce machines that need to shove order-processing thorugh various databases, these are usually protected with multiple layers of firewalls and audit proceedures. Finally, there are payroll machines, these should not be the same as the order/inventory machines, for the security reason. You are right, running encrypted data over 'trusted' network might help discourage employee fraud. As long as you've also taken measures to avoid clear-text passwords, etc. > So, do you trust all your employees and co-workers? How do you know > what the employee in the next office is doing or thinking? Are they > disgruntled? Maybe they want to know how much you're making? Perhaps > they are being paid by a competitor? Do you trust the people actually > running the network? Who maintains your routers? None of the people listed above should have either network or physical access to the machines containing financial data. This is kind-of network admin 101 stuff, so I'm not sure why we discuss it. Note also: if are a publically traded corporation, or a startup that needs to be audited because the VC asks for it, the auditors will review and question your firewall config, the network topology and the physical/network access thing. You will fail the audit if you get this wrong. On the other hand, chumps rule the world ... > I'm not proposing that we re-invent, I'm just concerned abou building complex, hard-to-maintain systems that don't have a clear scope of requirements that are to be solved. > investigate using ONC RPC as the marshalling system, which is much > less overhead than CORBA, Its not obvious to me that any RPC has lower overhead than corba. I'm tempted to beleive the opposite. Besides, remember that corba was invented to solve many of the evils and lack of function that rpc didn't/couldn't do. > have ONC RPC available) so we wont have to worry about portability. all platforms have corba as well. > I've just grabbed a book on CORBA, and I'm looking at information on > ORBit. I've certainly not bought into to one camp or another. > Actually, it's not that hard. We've been working towards this on the > list. For example, we've been discussing the Query API, which is one > such data-store API. We would still need to discuss the APIs to > obtain the lists of accounts, groups, etc. And we also need to > discuss the data write APIs, and data cache conherency (events & > notifications?) This is one reason I nominated corba. Many (but not all) of the api questions melt away, with an 'obvious' answer. Note events & notifications should work in corba, & I don't know how to do them with RPC, except as polls. > provided that we do limit the scope of where SQL enters the rest of > GnuCash. Yes, its important for me that we don't wake up one day and find sql code scattered throughou the gnucash engine in some adhoc way. That would be fatal. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: db2?
Herbert Thoma writes: > Hello! > > checking for db_open in -ldb2... no > configure: error: Cannot find db2. See the README for more info. > > README is not quite up to date ;-) > > What do I need for db2? Where can I find it? > Yet another dependency :-( I'm going to try to remove the dependency on db2 today. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: db2?
I'm not sure where -ldb2 is.. I don't have it on my Red Hat system, either. Although -ldb certainly contains db_open() (but -ldb1 doesn't). Perhaps we can make this check such that if -ldb2 fails it falls back to checking -ldb? -derek Herbert Thoma <[EMAIL PROTECTED]> writes: > Hello! > > checking for db_open in -ldb2... no > configure: error: Cannot find db2. See the README for more info. > > README is not quite up to date ;-) > > What do I need for db2? Where can I find it? > Yet another dependency :-( > > Thanks in advance, > Herbert. > -- > Herbert Thoma > FhG-IIS A, Studio Department > Am Weichselgarten3, 91058 Erlangen, Germany > Phone: +49-9131-776-323 > Fax: +49-9131-776-399 > email: [EMAIL PROTECTED] > www: http://www.iis.fhg.de/ > > ___ > gnucash-devel mailing list > [EMAIL PROTECTED] > http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: parent accounts, groups, and classes
David Merrill writes: > In light of the discussions we have been having over whether the > account group mechanism should be strictly hierarchical or whether an > account should be allowed to exist within more than one group, I am > considering providing both capabilities in the database. > > First, the group table would define groups. Each group would > contain arbitrary accounts, and accounts can belong to more than one > group via a third table, account_group. > > Second, the class table would define classes. Each class would contain > arbitrary accounts, but an account can belong to one and only one > class. Possibly, every account must belong to one class or another. > > These are implemented independently of the GUI, so the GUI can make > use of either or both of these mechanisms as it sees fit. It is easy > enough for me to do both rather than choose one. > > Regarding the parent account mechanism, can someone please explain to > me what this does for us that the account group mechanism above > doesn't? Are we actually using the account "tree" that it results in, > or just using it as another way to group accounts, where the top level > account is a dummy account? I'm not sure what you mean here. In the engine, the parent account mechanism is the group mechanism. There is no other way to specify subaccounts other than through groups. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
It's been rumoured that David Merrill said: > > Does this mean you are envisioning a server which can handle more than > one set of accounts and more than one set of transactions? Yes. Since its 'just' a set of cgi-bins, then there's a variety of easy ways of having leak-proof separation between different sets of accounts. Could be e.g. different URL's. Could be based on the user login. Could be based on 'virtual home', so e.g. you could have private-label/OEM branded web sites with diffferent look & feel of course different data, all being served with same server. There are even more tricks, won't bore you ... depends mostly on patience, competency and paranoia level of sysadmin. --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
It's been rumoured that Peter C. Norton said: > > Interesting, I haven't looked at libgnc_engine. Have you, in turn, looked > at the gda library being developed for gnome-db? Sort-of. libgda was one of the contributing technologies to the gnue GEAS component, I haven't exactly figured out the lineage. or the current status. But if I understand it right, it has my seal of approval as 'the right thing'. (i.e. almost certainly better than odbc for our uses). --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
It's been rumoured that Peter C. Norton said: > > > > Interesting, I haven't looked at libgnc_engine. Have you, in turn, looked > > > at the gda library being developed for gnome-db? > > > It's being separated from the gnome-db stuff, and it was done at the behest > of the gnue folks. It's not a here-and-now solution by itself, but if you > don't do anything that makes using it's interfaces later on it may be good. That last sentance doesn't parse. Is that approval, or disaproval of libgda ? --linas ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
On Thu, 21 Dec 2000, David Merrill wrote: > Is it possible that the answer is to take the existing engine code and > separate the Query API into calls into a corresponding API on the > server side? I'm still getting familiar with the code, so I have only > a vague concept of its functions. But obviously the existing Query API > is working. Yup. The goal of distributing an API is to make that API, which is implemented on the server, magically be callable from the client - ideally with no changes. However, we often have to add changes to deal with the fact that concurrent access by multiple users is now possible, so we can't store what is really session state in global variables on the server side, for example. ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
David Merrill <[EMAIL PROTECTED]> writes: > Is it possible that the answer is to take the existing engine code and > separate the Query API into calls into a corresponding API on the > server side? I'm still getting familiar with the code, so I have only > a vague concept of its functions. But obviously the existing Query API > is working. I think the Query API is only part of what we need. Yes, we can use the Query API and have it "execute" on the server, indeed that was my plan. However, we would still need the APIs to "write" changes to the data store (add/delete/modify splits/accounts/groups, etc.). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
db2?
Hello! checking for db_open in -ldb2... no configure: error: Cannot find db2. See the README for more info. README is not quite up to date ;-) What do I need for db2? Where can I find it? Yet another dependency :-( Thanks in advance, Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
parent accounts, groups, and classes
In light of the discussions we have been having over whether the account group mechanism should be strictly hierarchical or whether an account should be allowed to exist within more than one group, I am considering providing both capabilities in the database. First, the group table would define groups. Each group would contain arbitrary accounts, and accounts can belong to more than one group via a third table, account_group. Second, the class table would define classes. Each class would contain arbitrary accounts, but an account can belong to one and only one class. Possibly, every account must belong to one class or another. These are implemented independently of the GUI, so the GUI can make use of either or both of these mechanisms as it sees fit. It is easy enough for me to do both rather than choose one. Regarding the parent account mechanism, can someone please explain to me what this does for us that the account group mechanism above doesn't? Are we actually using the account "tree" that it results in, or just using it as another way to group accounts, where the top level account is a dummy account? -- Dr. David C. Merrill http://www.lupercalia.net Linux Documentation Project[EMAIL PROTECTED] Collection Editor & Coordinatorhttp://www.linuxdoc.org Finger me for my public key We turn the wheel to welcome her Every breath is sacred Opening, we welcome her Every breath is sacred As we walk this ancient path Every breath is sacred We are stronger than we know Every breath is sacred -- The Midwife's Song, Calla Unsworth ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: DB design document
On Thu, 21 Dec 2000 [EMAIL PROTECTED] wrote: > > investigate using ONC RPC as the marshalling system, which is much > > less overhead than CORBA, > > Its not obvious to me that any RPC has lower overhead than corba. > I'm tempted to beleive the opposite. No way - RPC is far more lightweight than CORBA. > Besides, remember that corba was invented to solve many of the evils > and lack of function that rpc didn't/couldn't do. Not true... CORBA is just RPC with an object model intestead of a procedural model. Which is a high level distinction. The problem is that IIOP is a much more complex protocol than ONC RPC, and harder to manage, which is what makes ORBs bloated. > > have ONC RPC available) so we wont have to worry about portability. > > all platforms have corba as well. Mine doesn't - I had to install it from a package on NetBSD. > > obtain the lists of accounts, groups, etc. And we also need to > > discuss the data write APIs, and data cache conherency (events & > > notifications?) > > This is one reason I nominated corba. Many (but not all) of the api > questions melt away, with an 'obvious' answer. Same with RPC, though... what do you perceive as the differences between CORBA and RPC? > Note events & notifications should work in corba, & I don't know how > to do them with RPC, except as polls. Callbacks are pretty standard. How would you do them in CORBA? > --linas ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
On Thu, 21 Dec 2000 [EMAIL PROTECTED] wrote: > It's been rumoured that Derek Atkins said: > > > > This is an interesting approach, but HTTP is _SLOW_. You have to > > ahh, what are you envisioning? a thousand hits a second? > www.linas.org serves up 20K pages a day, and serves up > cvs.gnucash.org, and its a 7 year old 486 whose load average > stays under 0.1 (and uptime would be years, if our power company > were reliable...) You're missing the point - HTTP is slow! It doesn't load the server, it's just slow! ABS -- Alaric B. Snell http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/ Any sufficiently advanced technology can be emulated in software ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: db2?
Herbert Thoma writes: > Hello! > > checking for db_open in -ldb2... no > configure: error: Cannot find db2. See the README for more info. > > README is not quite up to date ;-) > > What do I need for db2? Where can I find it? > Yet another dependency :-( The db2 dependency should be gone now. dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: client-server
Patrick Spinler <[EMAIL PROTECTED]> writes: > > > In short - Wow ! I like it. And if you'd seen Bill's latest embedded (in gtkhtml) guppi work, you'd be really excited. It's *painfully* slick. A bit of html-esque text and all of a sudden, an interactive guppi graph based on the data in the text embedded in our html widget alongside the other html bits. Very clever. -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
