On 03-Jan-2001, Christopher Browne <[EMAIL PROTECTED]> wrote:
> On Tue, 02 Jan 2001 14:50:24 CST, the world broke into rejoicing as
> [EMAIL PROTECTED] said:
> > This is way off-topic, but ...
> >
> > It's been rumoured that Tyson Dowd said:
> > >
> > > (Actually M$ has a lot more in the whole l
On 02-Jan-2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> We also have Derek Atkin's announcement that he has demo code working
> that does event notification via onc-rpc. Since soap/xml is our third
> candidate for network services, does it have something analogous that
> we're not aware of
On 02-Jan-2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Tyson,
>
> Re:
> It's been rumoured that Christopher Browne said:
> > CORBA Notification or Event services rather than changing GUIDs all the
> > time.
>
>
> We also have Derek Atkin's announcement that he has demo code working
> t
On Tue, 02 Jan 2001 14:50:24 CST, the world broke into rejoicing as
[EMAIL PROTECTED] said:
> This is way off-topic, but ...
>
> It's been rumoured that Tyson Dowd said:
> >
> > (Actually M$ has a lot more in the whole language infrastructure thing,
> > since their VM supports multiple language
On Tue, 02 Jan 2001 19:33:50 EST, the world broke into rejoicing as
Eugene Tyurin <[EMAIL PROTECTED]> said:
> On Tue, Jan 02, 2001 at 04:02:24PM -0500, Derek Atkins wrote:
> > David, a good start...
> >
> > David Merrill <[EMAIL PROTECTED]> writes:
> >
> > > We need to determine what level of g
On Tue, Jan 02, 2001 at 08:31:56PM -0600, John Hasler wrote:
> Eugene Tyurin writes:
> > 1. Nothing can be *deleted*. Entries can only be voided or superceded, but
> > they have to remain in the database for the audit/logging purposes.
>
> I proposed this some time ago. I think it not only pres
On Tue, Jan 02, 2001 at 07:33:28PM -0500, Eugene Tyurin wrote:
> On Tue, Jan 02, 2001 at 04:02:24PM -0500, Derek Atkins wrote:
> > David, a good start...
> >
> > David Merrill <[EMAIL PROTECTED]> writes:
> >
> > > We need to determine what level of granularity we want to provide for
> > > user p
On Tue, Jan 02, 2001 at 06:09:25PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > I'm planning to define permissions within the database itself. I want
> > the database to be aware of these permissions so they can be enforced
> > at that level. They could be exported
Eugene Tyurin writes:
> 1. Nothing can be *deleted*. Entries can only be voided or superceded, but
> they have to remain in the database for the audit/logging purposes.
I proposed this some time ago. I think it not only preserves an audit
trail but also simplifies the design.
> 2. All database
On Tue, Jan 02, 2001 at 04:02:24PM -0500, Derek Atkins wrote:
> David, a good start...
>
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > We need to determine what level of granularity we want to provide for
> > user permissions. Here is a simple set of permissions to start with.
> > Tell me wh
On Tue, 2 Jan 2001 [EMAIL PROTECTED] wrote:
> I suggest posting the demo code somewhere when you have it shaken
> out (including a thorough explanation of why this is an important
> feature/'good thing'). Can you abstract the interfaces to something
> generic?
> Is there some sort of rpc-speci
David Merrill <[EMAIL PROTECTED]> writes:
> I'm planning to define permissions within the database itself. I want
> the database to be aware of these permissions so they can be enforced
> at that level. They could be exported to the server in any format you
> want, including the you suggest.
I
On Tue, Jan 02, 2001 at 05:10:14PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > As long as they can do anything at all to data they have *just* entered,
> > I can live with that. I don't want a user to be unable to back up two
> > transactions and correct a typo wi
David Merrill <[EMAIL PROTECTED]> writes:
> As long as they can do anything at all to data they have *just* entered,
> I can live with that. I don't want a user to be unable to back up two
> transactions and correct a typo without calling a manager for
> approval. That is just not acceptable. And
On Tue, Jan 02, 2001 at 04:53:50PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > You were clear; I'm asking a slightly different question.
>
> Ok
>
> > I am not convinced that keeping clients up to date is necessary. I am
> > thinking of a paradigm just like a
On Tue, Jan 02, 2001 at 03:48:13PM -0600, Richard Wackerbarth wrote:
> >On Tue, Jan 02, 2001 at 04:02:02PM -0500, Derek Atkins wrote:
> > > I would think that add, delete, and update might be split into three
> > > different sets of permissions. I may give a secretary permission to
> > > add entr
On Tue, Jan 02, 2001 at 04:40:26PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > - restricted data entry (add/delete/update your own records only)
> >
> > > I would think that add, delete, and update might be split into three
> > > different sets of permissions. I
David Merrill <[EMAIL PROTECTED]> writes:
> You were clear; I'm asking a slightly different question.
Ok
> I am not convinced that keeping clients up to date is necessary. I am
> thinking of a paradigm just like a web interface to the engine, and you
> get new data by hitting refresh. If yo
>On Tue, Jan 02, 2001 at 04:02:02PM -0500, Derek Atkins wrote:
> > I would think that add, delete, and update might be split into three
> > different sets of permissions. I may give a secretary permission to
> > add entries, but I dont want him/her to be able to change or even
> > worse delete en
David Merrill <[EMAIL PROTECTED]> writes:
> - restricted data entry (add/delete/update your own records only)
>
> > I would think that add, delete, and update might be split into three
> > different sets of permissions. I may give a secretary permission to
> > add entries, but I dont want him/h
On Tue, Jan 02, 2001 at 04:25:53PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > Tell me why asynchronous calls are needed? Indeed, tell me why
> > callbacks are needed at all. What's so wrong with the client blocking
> > on a server call? If the call takes long eno
<[EMAIL PROTECTED]> writes:
> It's been rumoured that Derek Atkins said:
> > Again, see my long mail for a more "coherent" explanation.
>
> Do you envision keeping one socket open for the entire session?
> Or can a socket be torn down and rebuilt without loosing the session?
I envision keeping
David Merrill <[EMAIL PROTECTED]> writes:
> Tell me why asynchronous calls are needed? Indeed, tell me why
> callbacks are needed at all. What's so wrong with the client blocking
> on a server call? If the call takes long enough for the user to notice
> the blocking, it is a bug. K.I.S.S.
There
It's been rumoured that David Merrill said:
> The alternative is to assign a version number that increments each
> time the record is updated. Then we need only check one field to know
> if changes have been made. See any problems with that approach?
That works, and seems to solve other problems
It's been rumoured that Derek Atkins said:
> Again, see my long mail for a more "coherent" explanation.
Do you envision keeping one socket open for the entire session?
Or can a socket be torn down and rebuilt without loosing the session?
I envision, for example, a gnucash client staying up for
On Tue, Jan 02, 2001 at 04:02:02PM -0500, Derek Atkins wrote:
> David, a good start...
>
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > We need to determine what level of granularity we want to provide for
> > user permissions. Here is a simple set of permissions to start with.
> > Tell me wh
Tyson,
Re:
It's been rumoured that Christopher Browne said:
> CORBA Notification or Event services rather than changing GUIDs all the
> time.
We also have Derek Atkin's announcement that he has demo code working
that does event notification via onc-rpc. Since soap/xml is our third
candidate f
<[EMAIL PROTECTED]> writes:
> I suggest posting the demo code somewhere when you have it shaken
> out (including a thorough explanation of why this is an important
> feature/'good thing'). Can you abstract the interfaces to something
> generic?
I plan to do so, once I work out a few kinks. I
It's been rumoured that Derek Atkins said:
>
> In my solution, we would define two RPC programs, the forward
> (client->server) program which would be all the client-originated
> requests and server responses, and the callback/event (server->client)
> program, which would be the event notificatio
David, a good start...
David Merrill <[EMAIL PROTECTED]> writes:
> We need to determine what level of granularity we want to provide for
> user permissions. Here is a simple set of permissions to start with.
> Tell me what I've missed:
>
> - system administration (manage entire system)
> - corp
On Tue, Jan 02, 2001 at 03:51:33PM -0500, Derek Atkins wrote:
> Hi. Happy New Year.
Happy New Year!
Tell me why asynchronous calls are needed? Indeed, tell me why
callbacks are needed at all. What's so wrong with the client blocking
on a server call? If the call takes long enough for the user t
How about an object "version" number.. The GUID is static for an
object across all changes, but the version number is monotonically
incrased for every change. The audit trail can be based on the
version number. A client need only remember the version it has and
can easily determine that an obje
On Tue, Jan 02, 2001 at 02:38:45PM -0600, Christopher Browne wrote:
> On Tue, 02 Jan 2001 14:23:22 CST, the world broke into rejoicing as
> [EMAIL PROTECTED] said:
> > It's been rumoured that David Merrill said:
> > >
> > > I read this again and changed my mind, and I'll tell you why...
> > >
>
Hi. Happy New Year.
[ Note: This is probably a bit rambling, as I've got a lot floating
around in my head and I wanted to get it down in text. If, after
reading through this a few times you are still confused, please let me
know and I'll try to explain what I mean. -derek ]
As I've alluded to
This is way off-topic, but ...
It's been rumoured that Tyson Dowd said:
>
> (Actually M$ has a lot more in the whole language infrastructure thing,
> since their VM supports multiple language interoperation at the data
> level on the same machine -- no marshalling required.
Well, that's kind-o
On Tue, 02 Jan 2001 14:23:22 CST, the world broke into rejoicing as
[EMAIL PROTECTED] said:
> It's been rumoured that David Merrill said:
> >
> > I read this again and changed my mind, and I'll tell you why...
> >
> > When a record is changed, it is moved to the audit table, and a new
> > recor
It's been rumoured that David Merrill said:
>
> I read this again and changed my mind, and I'll tell you why...
>
> When a record is changed, it is moved to the audit table, and a new
> record is generated. That means a new GUID as well. So if the record
> exists in the transaction table, it is
I have decided to cut the feature of hierarchical coroporate entities
from initial release of gnucash-db. Now is your chance to jump and
scream and stamp your feet and tell me why you just can't live without
it, as well as what nifty stuff you can do with it. Otherwise, it will
wait for a later re
We need to determine what level of granularity we want to provide for
user permissions. Here is a simple set of permissions to start with.
Tell me what I've missed:
- system administration (manage entire system)
- corporate administration (manage one set of books)
- account administration (manage
On Mon, Jan 01, 2001 at 11:43:35PM -0800, Dave Peticolas wrote:
> David Merrill writes:
> > I read this again and changed my mind, and I'll tell you why...
> >
> > When a record is changed, it is moved to the audit table, and a new
> > record is generated. That means a new GUID as well. So if the
Notes on the new HTML generation infrastructure.
It's been time to fix the current HTML infrastructure for a while.
Pretty much every report reinvents any wheel it happens to need for
generating HTML markup and for the most part the reports are brutally
brittle; since they consist of literal HT
41 matches
Mail list logo
