for a single user (or single app). It wouldn't be
much more than using the right command line options, and
perhaps adding a little bit of socket code that would allow a
dedicated copy of postgres to run in a little `sandbox'."
This, of course, rais
Robert Graham Merkel <[EMAIL PROTECTED]> writes:
> Any objections?
Sounds good.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/
really
like to just support the most recent version or two, but for that to
work well, we really need the various distributions to package libguile
in a way that allows you to have multiple versions of the shared libs
installed simultaneously (a la Debian policy).
--
Rob Browning <[EMA
1.3.4
and 1.4 being OK is wrong.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
ile. Even *I'm* not going to use it for a bit,
and that's saying something.
You have been warned :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www
to recall that there was some ugliness with 1.3 anyway, and
that the guile people would really prefer people use 1.3.4. I can't
remember what the issue was, though...
Thanks for the info.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
-wrap.
That'd save some time, but it's not a big deal either way.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
s the problem.
I noticed this because I sent a long reply to your defmacro question,
but it bounced...
--Transcript of session follows ---
[EMAIL PROTECTED]
Remote connection was abruptly disconnected.
From: Rob Browning <[EMAIL PROTECTED]>
Subject: Re: guile ques
keypress or via a menu item. I can then imagine a mode that looks
like single-line mode, unless you hit that key, and when you hit
that key, only expands the current transaction to have N+1
splits. I think I might also want this mode to always show all
the existing splits fo
ked to the server over
a filesystem socket instead of a port.
Elegant or not, either would allow us to store the data in the user's
home dir, and wouldn't require *any* administrative setup/special
priveleges above/beyond a normal gnucash install, which can still be
done as a regular user.
le to access it either.
Yeah. Some of my mail to linas is bouncing too...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
R that I checked into the glib default hash functions, and
from at least a cursory inspection, I was worried that they might be a
little weak, but I didn't get a chance to inspect enough to be sure.
If anyone's motivated, it might be nice to see, and if they are weak,
we might want to grab
asdaq NASDAQ
uk_unit_trusts UK Unit Trusts
vanguardVanguard Investments
vwd Vereinigte Wirtschaftsdienste GmbH
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B9
uch flexibility we'd want to allow initially,
but changing the internals at some point might make accomodating
various different schemes easier.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
quot; rather than just "Savings".
Switching to the "flat list" approach would probably be more database
friendly, and it would simplify code that just needs to traverse all
the accounts...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
leading, and
hopefully we're going to to something much better soon, so why waste
the effort?
Does that address your concerns?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
ific set of accounts, this
probably gives you the general idea...
Perhaps this top-level structure should also be the one that knows
about the dataset's "back-end", and perhaps we should merge in all of
the "Session" semantics wrt locking, renaming, cloning, etc.
I think t
Derek Atkins <[EMAIL PROTECTED]> writes:
> Ok, I did find the most recent info pages, which I grabbed from CVS..
> But they still are useless.
Wow. I hadn't actually looked at them on that topic. Pretty
"sparse", no doubt...
--
Rob Browning <[EMAIL PR
when I solve the problem.
I've added your patch, and I've added support for const-string #f <-->
NULL translation at Bill's request. I'm waiting for him to test it,
and then I'll release 0.9.9.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A09
o the crash you were mailing me
> about.
I still wonder if we have 'cleanup everywhere we're supposed to.
Also, I need to add a 'const option so we can get rid of those silly
compiler warnings...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3
ot
going to make any sense, at least in certain parts of the heirarchy,
so perhaps it should be a per-level option, or perhaps it should only
become active if all the sub-account types match properly, or both...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
ve to deal with your enum patch, but I'll do that while
working on this.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
r CVS it appears that page splitting has been improved in more
> recent code. I'll have another play with it now.
Great.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL
questions.
Done. [EMAIL PROTECTED] should work now. Holler if it
doesn't.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
directory -- RPM can do that on its own
> +- Properly build both g-wrap and g-wrap-devel (info file into -devel)
> +- currently only one info file
Actually, this mostly answers my above questions, though I still have
only a little context for what's going on. In any case, I
he whole reporting system and GUI display system properly, but there
will probably be more noise about this on the list in a few days.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL
d multi-user
databases than network file systems, but the line's getting fuzzier
all the time these days. We *do* have a relational dataset, though,
so a perhaps a straightforward filesystem isn't really a perfect
match.
On the data communication side, there's also CORBA to consider.
(Fi
elpful. I'd also love to have better
documentation of related guile low-level issues like what do
GH_DEFER/ALLOW_INTS really do, and when do you need to use them?
Also perhaps a discussion of the changes that had to be made to Gtk+
with a commentary on why they helped would be really informati
ine, and how that relates to the
existing Session object. Some of my recent things make minor
improvements, but we need much more than that.
If you get a chance, you might want to look at Session.h and
Session.c...
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A0
GNU -> FA0B
MegaBank SuperFund -> EF11
Fid Retirement SuperFund -> AADF
ET brokerage DFFO -> AADF
All of the names in these views were assigned when the views were
created, but the underlying unique accounts still have their own
"official names", and somewhere, w
revious emails (one or two back I think). I
had suggested that perhaps a label at a given level might or might not
have an associated account, and (independent of that) might or might
not have subtotalling enabled...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3
ches gnucash's configure.in and acconfig.h.
>
> So, until we fix this, could everyone hold off for a moment or two?
OK, everyone have at it. 0.9.8's up there and should DTRT now.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
_
access struct members directly, you
have to write a set of helper functions that are then themselves
g-wrappable. This has it's drawbacks, but it also has the fairly
substantial advantage of keeping the semantics and implementation of
g-wrap simpler than they would be otherwise.
As a f
ray-destroy g-array)
result)
or, if we added a cleanup-arg? argument to the converter instead:
(let* ((acclist (list acct-1 acct-2 acct-3))
(g-array (frob-accounts (list->glib-glist 'Account* acclist
(glib-garray-
point is that it sounded initially (to me) like you were casting it
> as part of a "view", which I read with a capital 'V' from MVC, but
> it's actually part of the data model.
What's MVC?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04
ow everyone's busy, but has anyone else had a chance to work
> on this bug? It's confirmed, it's serious, and I'm having trouble
> tracking it down.
What's the status on this?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
I wanted to get this one out (which will hopefully fix the RPM
problems) before I dive into integrating the new enum support from
Robert.
2000-11-12 Rob Browning <[EMAIL PROTECTED]>
* configure.in: new version 0.9.12.
* rpm/spec.in: fix some bugs I introduced with a
ally important, so let me think about it for a bit and see if I can
come up with a good solution.
> I checked in some work today that removes the blank split lines in
> multi-line mode except for the current transaction. Thus, multi-line
> mode is now an 'auto' mode.
Woo hoo. I think I'll probably like that a lot :>
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
add something like a much clearer
"brokerage" window, etc.
Hopefully you get the idea.
> You're absolutely right, though - you don't just blindly copy the
> features of your competitor's product. That's what got us commercial
> bloatwa
(in-module module)
(c-name c-typedef-name)
;; return-type and parameters as for (function)
)
Ex:
(user-function PrintFunc
(in-module (Gtk))
(parameter in (type-and-name gpointer func_data))
(parameter in (type-and-name gchar* str)))
===
(typedef new-name
(in-module m
dumped into a
designated pane in your custom window. This would, of course, allow
all manner of stupid pet tricks for those willing to brave the schemey
waters.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-
This version should work with Bill's new patch (adds long and
long-long). It should also generate a new -devel RPM, though I can't
test that. Please let me know if you find mistakes.
ftp.gnucash.org:/pub/g-wrap/source/g-wrap-0.9.11.tar.gz
2000-11-08 Rob Browning <[EM
s is a "running out of RAM" bug? I know there have been
a lot of g-wrap induced memory leaks, some of which the recent
const-string fixes should eliminate, but I seem to recall thinking
that we need to make sure we're using cleanup/no-cleanup when we're
supposed t
that
stuff available from guile, and then I think about how much less
manpower we have to implement it, and *that* leads me to think about
g-wrap (or something similar) to help automate the process, and
automatically maintain the result...
Don't get me wrong. I'd love a solution that
that brings you up to a "minimal" prompt later if we
need it.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
, I've never used it. I
usually just cram in some display statements and try again :> :<
Check the info pages for "Debugger User Interface".
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-
y rather my window manager be in charge of
things, but I'd be happy to be proven wrong. Also, there'd be
*nothing* wrong with allowing a pane-centric approach as an option, or
is that what Gnome-MDI's supposed to do?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 5
d be happy to help with advise,
etc. on the libXML front.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
-> 0x5344A
Liabilities:CreditCards:AMEX -> 0xAFEA4
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
ction,
or even if they just change the date, the quote in the database can be
deleted/updated as appropriate, and these "transaction quotes" will
need to be distinguishable from "historical quotes" (right now those
would be quotes obtained via the online-mechanism) somehow.
Aga
ts either way. To a
substantial extent, I'm not the best person to evaluate this argument,
since I have little or no experience with CORBA, though I've done
plenty of DO/RPC related work.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
_
shed ways for handling this kind of thing, so we may be
able to just leverage those bits. Hard to tell before we really
consider the issues carefully...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-
Dave Peticolas <[EMAIL PROTECTED]> writes:
> That is what GnomeMDI is supposed to do -- allow the user to choose
> between windows or tabbed panes.
Nice idea. Make everybody happy. We can't have that.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F5
we get SQL
working, so I don't see the point in worrying about anything else...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
It's now in ftp.gnucash.org:/pub/g-wrap/source, and it may fix the
problem with guile-1.3.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnuma
is a reasonable
> way to store large data sets. XML is a cool technology, but just
> because a technology is cool doesn't mean that it's the right tool for
> the job.
Of course you're welcome to, but why would you waste time on this
rather than trying to go forward
y input anyone has for me?
OK, without me actually testing anything, just poking around, how
about the "Debugger options" section of the guile info pages? Does
that help? I see there's a way to turn on backtracing on error. I
think we may turn that off in gnucash unless the --debug opt
interest, and I hope this is the kind of feedback
you were looking for.
I figure you might also want a little more info about how/where the DB
would probably tie in to the code, but I thought I'd let you digest
this first :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 5
rd to
re-inventing that wheel.
So, presuming we keep our current frame of mind, the XML format may
very well only be the actual file format, short term.
> In any case, what follows is my brief patch which I'd appreciate if
> it were put into the CVS. Thanks!
Thanks very much for the w
Available at ftp.gnucash.org/pub/g-wrap/source:
2000-11-06 Rob Browning <[EMAIL PROTECTED]>
* release new version 0.9.10.
* guile/guile-types.scm (const-string): fix bug in scm->C conversion.
2000-11-05 Rob Browning <[EMAIL PROTECTED]>
Derek Atkins <[EMAIL PROTECTED]> writes:
> For the record, QIF importing no longer crashes, and I can
> successfully build the GnuCash CVS Mainline.
Great.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gy out of it. PLUS I won't have to try to
> dust off all my pitiful math skills.
[...]
> rgmerk and others, what think ye?
Sounds like an excellent idea to me.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
e-modules (gwp open-gl))
and have it suck in the system and g-wrap libs you need automagically
at runtime, and a fancier type system so that we can handle fancier
types (like glib containers) with more transparency. The latter is
tougher, and I need to do some head-scratching before I can tell what
#x27;s going to be difficult to generate
reports that know exactly what really happened...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
involve defining the SQL tables
we need. I don't see how that involves a "binary data format". I
must not understand what you mean.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Derek Atkins <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>
> > The 50MB of RAM you're worried about is a *BUG*, and it needs to be
> > fixed. Other than that, and some performance work that seems fairly
>
> Is this a bug we
s I mentioned before, this might even mean getting rid of the
arbitrary hierarchical frames stuff.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
le as allowing the user to
use the DB they've already deployed, and as we move into the
small-business arena, allowing people to stick data in *their* DB will
probably become more critical. Though, even there, as long as we have
ways to interface with other DBs (i.e. batch push/pull) tha
; problem areas. Designing the database won't be hard (I've done many
> financial apps in my time!), and writing SQL will be pretty
> straightforward (the engine does all the work, really).
I agree.
> That's the idea, anyway. :-D
Thanks much for the help.
--
Rob Br
DBMS server, sharing access with other users and
> all that.
Well it looks like David Merrill may be interested in starting work on
the SQL stuff. We'd love to have your help/input if you're
interested.
Thanks
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
ount set in various
meaningful (to them) ways.
We might also use the framework internally for some very specific,
rigid organizations, but thats a different point.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
[...]
> Hopefully I've given you enough pointers to get started.
Thanks very much. I glanced at the manpage briefly, and it's quite
interesting. I appreciate the pointer, and I'll definitely have to
spend a bit of time grokking it.
--
Rob Brownin
h is
available via g-wrap-config. We already have a Makefile var with that
value that's determined in configure.in that we use in generating
gnucash.c.in. We just need to add it to this Makefile.am.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
f the thing you have, and value it's value.
Though quantity, taken by itself, is ambiguous, I'm not sure it's so
bad when within the context of a split. It would be hard to confuse
it with any of the other fields, and it's arguably better than
damount.
In any case, better names, w
Dave Peticolas <[EMAIL PROTECTED]> writes:
> My best guess is that it stands for 'debit'.
I had always thought it meant d(elta)amount.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-
ertainly
> have their own table, so there will be an 'explicit' list of them.
And I've even thought about adding such a list to gnucash from time to
time...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
x27;t
have RATIONAL_64 as a type. :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
laces, etc.
At least this is why we've done what we've done up to now.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
would cause Debian or other free
> software distributors to consider gnucash to be non-free in any
> way. We cannot and will not be cavalier about software licensing.
What Bill said ... twice.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F
t thinking too much about it) we
can use whatever encryption/authentication we want -- possibly even
just GPG encrypted chunks :>
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
's copyright, etc.)
rules, we certainly can't expect them to enforce our licenses when the
shoe is on the other foot.
This is not a huge issue -- I don't think we have any problems that
won't be easy to solve to everyone's satisfaction, but it is important
to get t
cryptic passwords like
GPG/SSH etc.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
proxy that can handle the messy details of
storing arbitrary length strings (if that's even possible) in DBs that
don't handle them natively.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mai
- - - -> || (gnc_engine <-> ui)
(server) || <- - - - - -> || (gnc_engine <-> ui)
and we need to be thinking about what we *require* be done where.
I.e. does the DB just serve up raw records or do we require it to be
able to "do the math"
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Rob Browning is going the price database, so he will be posting a
> requirements/design doc soon.
Getting started on this now, so it's time to talk :>
> It may be that gnucash doesn't need to use the price db to store
>
Dave Peticolas <[EMAIL PROTECTED]> writes:
> It should be splits -- I wasn't being very specific in that email.
No problem, just wanted to make sure I was thinking straight myself.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A
it; I'm human. If it's not, then I think it
> should be.
Well, we're using the standard md5sum code, and AFAIK, that's on very
solid mathematical footing. I don't have references handy ATM,
though. (Anyone?)
--
Rob Browning <[E
es anyone have any
objections to this? If not, then unless someone else wants to do it,
I'll start working on this, and fixing up the file read code to
properly convert old "zero-price" splits -> split quotes immediately.
Speak now...
Thanks
--
Rob Browning <[EM
t be very efficient if stored in a
table with a bunch of other fixed length fields. In that situation,
perhaps we make a table of all the fixed length (the more
computational/indexable fields), and another table of blobs that are
indexed to the first table by GUID.
I think this is the kind of quest
rver-proxy and gnc-client
ourselves.
> That will be the nature of the first implementation. I always design
> way farther than I implement, so that when the later stuff gets
> implemented it has already been planned for. At some point probably
> weeks from now, I will put much more ser
one could, in confidence, pick one dbms and adopt it
> without reservation, the discipline of building an API to separate
> it from the rest of the application generally results in a cleaner,
> more maintainable system.
Agreed.
Thanks again for all the input.
--
Rob Browning
ew projects we
can beg/borrow from.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
even sure there
was any consensus that it was the right thing to do. Hoever, I
thought David might want to a least be aware of the discussion.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing li
r that?
In point of fact, I don't really care which way we go, and I think you
know me well enough to know that difficulty in implementation isn't
usually at the top of my criteria list. I'd just like to make sure we
pick the best answer given what we know and where we think we might
anges, but which ones? This is getting messy.
I defintely don't know enough right now to know what the "constants"
here are. Company name changes are obviously ephemeral, but, thinking
about it, it seems like ticker symbols, and perhaps even exchanges
could be too...
--
Rob Browni
ust require that the account
restore be nested inside a (or whatever) block that
handles ending the group's edits.
One thing that does still bother me a bit is that there's an assymetry
for groups now. We don't have an xaccGroupBeginEdit to balance the
commit edit. Perhaps we should
test.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
nother mail, I kinda think we might be better
served moving to one global, flat account list and having various
hierarchical structures pointing into that for display/organization
purposes, but even if we decide to do taht, it's probably not going to
happen in the next month or so.
FWIW.
er than creating
categories in quicken. As long as you don't do something silly like
trying to open up one of these expense accounts, you can just go
along, blissfully pretending like they're just categories.
Is that not sufficient?
--
Rob Browning <
place to add any code we need if we want to
make the encryption/authentication system more modular. Seems like a
more flexible approach in the long run, but of course it does have
it's own set of drawbacks.
FWIW.
--
Rob Browning <[EMAIL P
1 - 100 of 818 matches
Mail list logo