It's been rumoured that Derek Atkins said:
>
> Well, no.. WebNFS was supposed to allow anonymous NFS service via
> HTTP. It was not supposed to provide arbitrary RPC service over HTTP.
actually, I thought webnfs was supposed to be an alternative to http,
preciesly because http (circa 94/95) was
On Fri, 22 Dec 2000, Al B. Snell wrote:
> alaric@lust$ time rpcinfo -n 111 -u www.demon.net 10 4
When I am next at home I can NFS mount something and time stat() on an NFS
file if you like.
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net
On Fri, 22 Dec 2000 [EMAIL PROTECTED] wrote:
> > No way - RPC is far more lightweight than CORBA.
>
> I am an rpc novice ... so excuse me, but what about the overhead of
> having to contact 3 or 4 different servers, e.g. portmapper, statd,
> rpciod, and all that? My impression was that this was
It's been rumoured that Al Snell said:
>
> No way - RPC is far more lightweight than CORBA.
I am an rpc novice ... so excuse me, but what about the overhead of
having to contact 3 or 4 different servers, e.g. portmapper, statd,
rpciod, and all that? My impression was that this wasn't
a particul
On 22 Dec 2000, Derek Atkins wrote:
> > I also thought they introduced considerable latency: viz, having to
> > look up a service on one port number, (using udp, no less), and then
> > another, and then yet another lookup, just to find the service.
>
> Not exactly. If you do use portmap (which
<[EMAIL PROTECTED]> writes:
> uhh, I am not an expert, but: what about the deamons rpciod, lockd,
> rpc.statd, portmap? Last I understood, these had a variety of ways
> to be hijacked, via replay attacks, bogus udp packets, etc.
Um... rpciod, lockd, and rpc.statd are all NFS daemons. Yes,
On Fri, 22 Dec 2000 [EMAIL PROTECTED] wrote:
> > Then, unfortunately, you're tempted to be wrong. RPC (I'm going to
> > presume RPC == SunRPC == ONC RPC from now on) tries to bite off a much
> > smaller problem space than CORBA does, so the required solution space
> > is also much smaller.
>
It's been rumoured that Derek Atkins said:
> we're going to have to accept _some_ of the complexity in order to do
> what we want.
>
> As for the clear requirements, you are correct -- we do need a clear
> set of requirements. I've been trying to state what my requirements
> are, in terms of sec
Christopher Browne <[EMAIL PROTECTED]> writes:
> Yes, indeed. The "CORBA way" would be to establish whatever set of
> interfaces are useful for distributing the application.
>
[snip]
>
> Even if the final conclusion is to not use CORBA, I would suggest that
> organizing the set of "published fu
On 22 Dec 2000, Derek Atkins wrote:
> Also, it's not that hard to create your own transport with security.
> A simple extention to rpc_tcp.c to build TCP-based transports is all
> you really need. I've done it once before, and it works well.
> Luckily, the RPC interface is standardized across al
Al Snell <[EMAIL PROTECTED]> writes:
> As for security... if we used Corba with ORBit, then we could just
> piggyback the Orbit-SSL stuff when it comes out; if we use ONC RPC, not
> all implementation provide the security extensions, but I'm pushing for a
> portable ONC RPC implementation with se
Most users of GnuCash won't know that they want encryption of network
traffic. It's our job to know that and put it in there for them,
automatically, rather than expecting them to set up VPNs and firewalls and
stuff. Chumps rule the world.
> As for the clear requirements, you are correct -- we d
On Thu, 21 Dec 2000, Christopher Browne wrote:
> Even if the final conclusion is to not use CORBA, I would suggest that
> organizing the set of "published functions" in IDL form may be very useful
> in establishing what functions the GnuCash server should accept as calls.
>
> By the way, supposin
<[EMAIL PROTECTED]> writes:
> 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.
Thanks for the warning ;)
> It's been rumoure
On 21 Dec 2000 14:19:40 EST, the world broke into rejoicing as
Derek Atkins <[EMAIL PROTECTED]> said:
> 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
> >
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 th
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:
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 ob
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 ob
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 ma
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, Accoun
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
"C
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
<[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 t
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 ->
"Phillip Shelton" writes:
>
> ACCOUNT
> ---
> account_guidchar32
> parent_account_guid char32 -> account.account_guid
> group_guid char32 -> account_group.group_guid
> account_typeinteger ->
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Currently, the reconcile dialog is all-or-nothing. Either you finish
> the reconciliation, or nothing is changed. Here is my plan for postponing
> a reconciliation:
Once again, Dave plans to implement something I hadn't even fully
realized I *really*
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_co
It's been rumoured that Rob Browning said:
>
> [EMAIL PROTECTED] writes:
>
> > I don't think there are any. Virtually all sql db's support a
> > common basic set of functions, and its hard for me to think of a
> > good example where gnucash would need/want to use something that
> > wasn't stand
[EMAIL PROTECTED] writes:
> I don't think there are any. Virtually all sql db's support a
> common basic set of functions, and its hard for me to think of a
> good example where gnucash would need/want to use something that
> wasn't standard.
Say we decide we need to always perform some particu
David Merrill writes:
> >
> > In the past yes, but now they are set to the date you choose
> > in the 'reconciliation info' window that pops up when you
> > start a reconciliation. By default, it is the current date.
>
> So when you go back to complete a reconciliation the date will already
> be
It's been rumoured that Rob Browning said:
>
> [EMAIL PROTECTED] writes:
>
> > at some point or another, gnc-engine must convert whatever its doing
> > to plain-old SQL statements. The standard sql client side libraries
> > just send these to the server via unix-dmoain sockets or tcp sockets.
David Merrill writes:
> On Wed, Dec 20, 2000 at 10:21:30AM -0600, Bill Gribble wrote:
> > On Wed, Dec 20, 2000 at 09:58:25AM -0500, David Merrill wrote:
> > > So an account group can belong to another account group? The current
> > > schema doesn't provide for that. Should it? If it does, then we
It's been rumoured that Jean-David Beyer said:
> > More accurately
> >
> > (sql server) || <- - - - - -> || (sql-client-lib <-> gnc_engine <-> ui)
> >
> > at some point or another, gnc-engine must convert whatever its doing
> > to plain-old SQL statements. The standard sql client side librarie
It's been rumoured that Derek Atkins said:
>
> The problem is that using TCP sockets is completely insecure. This is
> also a problem with Xlib (which is why many people tunnel X in SSH :)
> We want to avoid over-the-network communications in-the-clear, by
> using encryption. I would also like
It's been rumoured that Jean-David Beyer said:
>
> Patrick Spinler wrote:
> >
> > Earlier in this converstation, Linas mentioned that SSLizing any
> > application isn't very difficult.
> >
> > Certainly for the [GPL, I assume you mean] license databases that we're
> > considering using here
> >
Patrick Spinler wrote:
>
> Derek Atkins wrote:
> >
> > [EMAIL PROTECTED] writes:
> >
> > > ?
> > > More accurately
> > >
> > > (sql server) || <- - - - - -> || (sql-client-lib <-> gnc_engine <-> ui)
> > >
>
> Earlier in this converstation, Linas mentioned that SSLizing any
> application isn't ve
Derek Atkins wrote:
>
> [EMAIL PROTECTED] writes:
>
> > ?
> > More accurately
> >
> > (sql server) || <- - - - - -> || (sql-client-lib <-> gnc_engine <-> ui)
> >
Earlier in this converstation, Linas mentioned that SSLizing any
application isn't very difficult.
Certainly for the license databas
[EMAIL PROTECTED] writes:
> at some point or another, gnc-engine must convert whatever its doing
> to plain-old SQL statements. The standard sql client side libraries
> just send these to the server via unix-dmoain sockets or tcp sockets.
> If its tcp sockets, you don't 'care' wheere the sql se
[EMAIL PROTECTED] wrote:
>
> It's been rumoured that Rob Browning said:
> >
> > [EMAIL PROTECTED] writes:
> >
> > > > > (server) || <- - - - - -> || (gnc_engine <-> ui)
> > >
> > > here, the dotted line is just sql. Don't have to invent anything to
> > > make this work.
> >
> > But is this
[EMAIL PROTECTED] writes:
> ?
> More accurately
>
> (sql server) || <- - - - - -> || (sql-client-lib <-> gnc_engine <-> ui)
>
> at some point or another, gnc-engine must convert whatever its doing
> to plain-old SQL statements. The standard sql client side libraries
I'm not convinced that "g
It's been rumoured that Rob Browning said:
>
> [EMAIL PROTECTED] writes:
>
> > > > (server) || <- - - - - -> || (gnc_engine <-> ui)
> >
> > here, the dotted line is just sql. Don't have to invent anything to
> > make this work.
>
> But is this sufficient? Overstating things a bit, this
[EMAIL PROTECTED] writes:
> > > (server) || <- - - - - -> || (gnc_engine <-> ui)
>
> here, the dotted line is just sql. Don't have to invent anything to
> make this work.
But is this sufficient? Overstating things a bit, this may rely on
every sql server we support being able to do every
David Merrill <[EMAIL PROTECTED]> writes:
> That's not terribly hard to implement, but we need to decide now. It
> would be very hard to change once implemented and in production. My
> design now does not allow for this, per comments from other folks.
As I mentioned in another mail, I kinda thin
On Wed, Dec 20, 2000 at 10:21:30AM -0600, Bill Gribble wrote:
> On Wed, Dec 20, 2000 at 09:58:25AM -0500, David Merrill wrote:
> > So an account group can belong to another account group? The current
> > schema doesn't provide for that. Should it? If it does, then we have
> > account groups which
On Wed, Dec 20, 2000 at 09:58:25AM -0500, David Merrill wrote:
> So an account group can belong to another account group? The current
> schema doesn't provide for that. Should it? If it does, then we have
> account groups which can contain other account groups or accounts. the
> sub-groups can con
On Wed, Dec 20, 2000 at 10:18:01AM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > I'm going to use lots of GUIDs.
>
> A GUID is just a unique index into a table, right? So an account_guid
> would be an index to a particular account, etc.
Exactly.
--
The great se
David Merrill <[EMAIL PROTECTED]> writes:
> I'm going to use lots of GUIDs.
A GUID is just a unique index into a table, right? So an account_guid
would be an index to a particular account, etc.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Stude
On Wed, Dec 20, 2000 at 09:58:25AM -0500, David Merrill wrote:
> On Wed, Dec 20, 2000 at 08:43:18AM -0600, Bill Gribble wrote:
> > On Wed, Dec 20, 2000 at 11:57:47AM +1000, Phillip Shelton wrote:
> > > An account group is just what it sounds like, a group of accounts.
> > >
> > > All accounts in
On Wed, Dec 20, 2000 at 08:43:18AM -0600, Bill Gribble wrote:
> On Wed, Dec 20, 2000 at 11:57:47AM +1000, Phillip Shelton wrote:
> > An account group is just what it sounds like, a group of accounts.
> >
> > All accounts in an account group must be denominated in the same commodity.
>
> I know t
On Wed, Dec 20, 2000 at 03:09:50PM +1000, Phillip Shelton wrote:
> Depends on how you use groupings. Are we going to allow someone to have an
> account that is part of credit and part of clothes, part of sport, part of
> hobbies ...
>
> There was a question some time ago about being able to get a
On Wed, Dec 20, 2000 at 11:57:47AM +1000, Phillip Shelton wrote:
> An account group is just what it sounds like, a group of accounts.
>
> All accounts in an account group must be denominated in the same commodity.
I know the attribution is screwy there but I just want to point out
that in gnucas
"Phillip Shelton" writes:
> Depends on how you use groupings. Are we going to allow someone to have an
> account that is part of credit and part of clothes, part of sport, part of
> hobbies ...
>
> There was a question some time ago about being able to get away from having
> a tree of accounts an
David Merrill writes:
> On Wed, Dec 20, 2000 at 11:57:47AM +1000, Phillip Shelton wrote:
> >
> > ACCOUNT_GROUP
> > -
> > group_guid char32
> > group_name textname of the group of accounts
> > notes textany notes t
Depends on how you use groupings. Are we going to allow someone to have an
account that is part of credit and part of clothes, part of sport, part of
hobbies ...
There was a question some time ago about being able to get away from having
a tree of accounts and moving to a connected graph. This w
On Wed, Dec 20, 2000 at 12:05:29PM +1000, Phillip Shelton wrote:
> You will possibly need to keep a checkpoint on the share_* values as well.
>
> These are, I assume, the balances for the damounts in the splits?
Yes. I corrected it.
--
Dr. David C. Merrill http://www.luperc
On Tue, Dec 19, 2000 at 06:57:34PM -0800, Dave Peticolas wrote:
> "Phillip Shelton" writes:
> >
> > ACCOUNT_GROUP
> > -
> > group_guid char32
> > group_name textname of the group of accounts
> > notes textany note
On Wed, Dec 20, 2000 at 11:57:47AM +1000, Phillip Shelton wrote:
>
> ACCOUNT_GROUP
> -
> group_guid char32
> group_name textname of the group of accounts
> notes textany notes the user wishes to make
>
> An accou
"Phillip Shelton" writes:
>
> ACCOUNT_GROUP
> -
> group_guid char32
> group_name textname of the group of accounts
> notes textany notes the user wishes to make
>
> An account group is just what it sounds like, a
You will possibly need to keep a checkpoint on the share_* values as well.
These are, I assume, the balances for the damounts in the splits?
Phill
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucas
ACCOUNT_GROUP
-
group_guid char32
group_name textname of the group of accounts
notes textany notes the user wishes to make
An account group is just what it sounds like, a group of accounts.
All accounts in an ac
It's been rumoured that David Merrill said:
>
> On Sat, Dec 16, 2000 at 09:52:14AM -0600, Rob Browning wrote:
> > David Merrill <[EMAIL PROTECTED]> writes:
> >
> > > Please take a look at the latest revision of my design document and
> > > give me some feedback.
>
> > * design an API that's
On Tue, Dec 19, 2000 at 12:21:52AM -0800, Dave Peticolas wrote:
> "Phillip Shelton" writes:
> > (Taken from David M's schema.txt)
> > SPLIT
> > -
> > account_guidchar32 ->account.account_guid
> > transaction_guidchar
> > ->transaction.transact
"Phillip Shelton" writes:
> (Taken from David M's schema.txt)
> SPLIT
> -
> account_guidchar32 ->account.account_guid
> transaction_guidchar
> ->transaction.transaction_guid
> split_guid char32
> action
(Taken from David M's schema.txt)
SPLIT
-
account_guidchar32 ->account.account_guid
transaction_guidchar
->transaction.transaction_guid
split_guid char32
action ???
status
On Mon, Dec 18, 2000 at 12:56:58PM -0500, Derek Atkins wrote:
> Rob Browning <[EMAIL PROTECTED]> writes:
>
> > "Phillip Shelton" <[EMAIL PROTECTED]> writes:
> >
> > > Then, as a lazy programmer, how much of this can we legally steal
> > > from other server-proxies?
> >
> > Dunno, but if we go t
On Mon, Dec 18, 2000 at 11:53:22AM +1000, Phillip Shelton wrote:
> (Taken from David M's schema.txt)
>
> The scu is used as the denominator in splits against this account. It is
> enforced by the engine. Why do we not just use what is defined for the
> commodity?
>
>
> Dave P has answered this
[EMAIL PROTECTED] (Bill Gribble) writes:
> On Mon, Dec 18, 2000 at 01:00:56PM -0500, Derek Atkins wrote:
> > This is a reasonable approach, although I think we still want (need?)
> > to be flexible enough to make some rather robust queries. For
> > example, I can certainly see where you might wa
On Mon, Dec 18, 2000 at 01:00:56PM -0500, Derek Atkins wrote:
> This is a reasonable approach, although I think we still want (need?)
> to be flexible enough to make some rather robust queries. For
> example, I can certainly see where you might want to search for
> transactions in an account betw
Christopher Browne <[EMAIL PROTECTED]> writes:
> It shouldn't be a situation of the GUI submitting database queries;
> instead, the GUI should submit _transaction_ queries to the engine, and
> the engine can then do what it needs.
This is a reasonable approach, although I think we still want (ne
Rob Browning <[EMAIL PROTECTED]> writes:
> "Phillip Shelton" <[EMAIL PROTECTED]> writes:
>
> > Then, as a lazy programmer, how much of this can we legally steal
> > from other server-proxies?
>
> Dunno, but if we go this way, all we really need is some reasonably
> good server code, and I suspe
Unfortunately, David Merrill is right. Is is difficult at best to store
data of arbitrary length in a database. This is a large part of the
reason why BLOBs were introduced. BLOBs have their own drawbacks,
though, like not being able to index and search on them.
The best you can do in a "trad
On Sun, 17 Dec 2000 23:11:15 EST, the world broke into rejoicing as
David Merrill <[EMAIL PROTECTED]> said:
> On Sun, Dec 17, 2000 at 05:43:57PM -0600, Rob Browning wrote:
> > Jean-David Beyer <[EMAIL PROTECTED]> writes:
> >
> > At this point, as I've said, I now tend to think that we should jus
On Sun, Dec 17, 2000 at 05:43:57PM -0600, Rob Browning wrote:
> Jean-David Beyer <[EMAIL PROTECTED]> writes:
>
> At this point, as I've said, I now tend to think that we should just
> plan to handle encryption/authentication directly by having a
> server-side gnucash daemon.
I think so, too.
>
"Phillip Shelton" <[EMAIL PROTECTED]> writes:
> Accounts can have subaccounts. The subaccounts are identified by the
> parent_account_guid, which indicates the parent account.
We have also discussed the possibility that we might switch to just
having a flat account list, and then have another st
"Phillip Shelton" <[EMAIL PROTECTED]> writes:
> Then, as a lazy programmer, how much of this can we legally steal
> from other server-proxies?
Dunno, but if we go this way, all we really need is some reasonably
good server code, and I suspect that there are quite a few projects we
can beg/borrow
On Sun, Dec 17, 2000 at 05:21:27PM -0600, Rob Browning wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > > We need to be more specific about what we need in terms of query
> > > efficiency. It may make sense to use one storage/indexing strategy
> > > for non-text fields and a completely d
(Taken from David M's schema.txt)
ACCOUNT
---
account_guidchar32
parent_account_guid char32 -> account.account_guid
account_typeinteger ->
account_types.acct_type_code
account_codechar20 a mn
Phillip Shelton wrote:
>
> > -Original Message-
> > This can certainly be a problem, but if the person who has the role of
> > database designer normalizes (preferably to at least 3BNF*)
> > the database
> > when designing it, the times you would want to change its basic design
> > should
> -Original Message-
> David Merrill <[EMAIL PROTECTED]> writes:
> As you also suggest later in this message, the more I think about it
> and read other people's comments, unless I'm overlooking something
> obvious, having a gnc-server-proxy now seems to me inevitable. It
> provides us
> -Original Message-
> This can certainly be a problem, but if the person who has the role of
> database designer normalizes (preferably to at least 3BNF*)
> the database
> when designing it, the times you would want to change its basic design
> should be extremely few, since each table
Jean-David Beyer <[EMAIL PROTECTED]> writes:
> I just looked at it and it just showed me how much I do not know
> about double-entry bookkeeping. I am familiar with the Quicken model
> (if I may call it that), and have no predisposition to it. But the
> GnuCash model requires a different mind set
David Merrill <[EMAIL PROTECTED]> writes:
> > * design an API that's exactly what we need, regardless of the DB
> > involved, and plan to just have a server-side gnucash daemon
> > that manages the DB interface, dealing with any limitations of
> > the DB on the server-side
David Merrill <[EMAIL PROTECTED]> writes:
> > We need to be more specific about what we need in terms of query
> > efficiency. It may make sense to use one storage/indexing strategy
> > for non-text fields and a completely different one for text fields.
> > It's my opinion that having arbitraril
On Sun, Dec 17, 2000 at 10:18:02AM -0600, Bill Gribble wrote:
> On Sat, Dec 16, 2000 at 12:29:50PM -0500, David Merrill wrote:
> > Unfortunately, however, allowing *very* large text fields has serious
> > drawbacks in databases that it does not have in XML. You pay a price
> > in terms of storage
On Sat, Dec 16, 2000 at 12:29:50PM -0500, David Merrill wrote:
> Unfortunately, however, allowing *very* large text fields has serious
> drawbacks in databases that it does not have in XML. You pay a price
> in terms of storage space and indexing, which translates to query
> execution speed. Not j
On Sat, Dec 16, 2000 at 03:19:48PM -0500, Jean-David Beyer wrote:
> David Merrill wrote (in part):
> >
> > On Sat, Dec 16, 2000 at 09:52:14AM -0600, Rob Browning wrote:
> > > David Merrill <[EMAIL PROTECTED]> writes:
> > >
> > > > Please take a look at the latest revision of my design document an
David Merrill wrote (in part):
>
> On Sat, Dec 16, 2000 at 09:52:14AM -0600, Rob Browning wrote:
> > David Merrill <[EMAIL PROTECTED]> writes:
> >
> > > Please take a look at the latest revision of my design document and
> > > give me some feedback.
I just looked at it and it just showed me how
On Sat, Dec 16, 2000 at 12:29:54PM -0500, Jean-David Beyer wrote:
> I imagine in an open-source context, management details are even more
> difficult to achieve, since there is no enlightened CEO who can decree
> that the decisions of the principal architect are law. It seems to have
> worked with
On Sat, Dec 16, 2000 at 09:52:14AM -0600, Rob Browning wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > Please take a look at the latest revision of my design document and
> > give me some feedback.
Cool.
> Finally got a chance to glance at it and to catch up on the current
> discussion
On Sat, Dec 16, 2000 at 09:18:39AM -0600, Rob Browning wrote:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > Anyway we can avoid putting arbitrary limits on the lengths of text
> > fields like account names & such? Currently gnucash imposes no such
> > limits and I think it would be good to k
David Merrill wrote (in part):
> Don't you know that is one of the big problems with enterprise
> software design? It's all designed by committee!
>
I sure do. I worked at a large, formerly well regarded, research and
development organization, and we had to deal with that all the time
(with litt
On Sat, Dec 16, 2000 at 08:17:22AM -0500, Jean-David Beyer wrote:
> David Merrill wrote:
> >
> > On Sat, Dec 16, 2000 at 02:15:21AM -0500, James LewisMoss wrote:
> > > > On Thu, 14 Dec 2000 13:23:55 -0500, David Merrill
><[EMAIL PROTECTED]> said:
> > >
> > > David> On Thu, Dec 14, 2000 at 1
David Merrill <[EMAIL PROTECTED]> writes:
> Please take a look at the latest revision of my design document and
> give me some feedback.
Finally got a chance to glance at it and to catch up on the current
discussion. Most of the points I was going to mention "first-pass"
other people already br
Rob Browning wrote (in part):
>
> Steve Greenland <[EMAIL PROTECTED]> writes (also in part):
>
> Agreed. Basically, the point was that we take the FSF, the GPL, and
> free-software very seriously here, so we're not going to skimp on the
> details, and I'm glad you brought this up. I hadn't rea
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Anyway we can avoid putting arbitrary limits on the lengths of text
> fields like account names & such? Currently gnucash imposes no such
> limits and I think it would be good to keep it that way. I know
> postgres has arbitrary length text fields, but
Dave Peticolas <[EMAIL PROTECTED]> writes:
> We may have to gather some usage information -- I have no idea what
> people typically use, but 50 seems a bit small.
And passwords should go to at least 64, I'd probably say more like
128. This allows people to choose safer, less cryptic passwords l
Ignoring for the moment *any* issues of "what the right license is".
There is a fundamental legal issue here. We chose a particular
license for GnuCash. We now have make sure whatever we do in the
future remains within the spirit and letter of that license, or we
have to change that license som
Steve Greenland <[EMAIL PROTECTED]> writes:
> wouldn't be able to distribute it at all. (I'll add "I'm pretty sure" to
> that last statement, as I certainly don't speak in any official way for
> the Debian project
Who does, really :>
> Your certainly welcome (even encouraged) to bring the topic
[EMAIL PROTECTED] (Bill Gribble) writes:
> Rest assured that the gnucash developers are just as concerned about
> this stuff as you are. We absolutely do not want to use any
> component that makes any problems for distributing gnucash under
> straight GPL, nor do anything that would cause Debian
1 - 100 of 165 matches
Mail list logo
