New HTML generation infrastructure for reports

[Bill Gribble]

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 HTML strings embedded in Scheme
code, you will have a very hard time customizing the way they look or
what they do.

I am mostly done with a completely new system for generating HTML in
reports.  It's not terribly complicated or sophisticated but it does
have some nice features, including support for CSS-like "styles" for
markup that can by changed on the fly and a "style sheet" template
mechanism that creates a new kind of entity, the style sheet, that can
influence the overall appearance and style of any report which uses
it.  This will allow folks to create custom style sheets which make
all of their reports share a common look and feel, without having to
modify the reports.

My goal is to make reports much shorter and cleaner, trying to leave
all the fancy formatting stuff to the style sheets, and to make it
possible to make reports both arbitrarily good-looking and similar to
each other.  That will make it easier to use reports in different
contexts (printed formal statements vs.  short tables embedded in a
big window with other short statements) and will make it easier for
people to scavenge other people's reports for code to make new
reports.

I would like report writers and other interested parties to have a look
at this document and the bits of sample code in it and let me know if 
this looks reasonable. 

By convention, I name all Guile "record types" with surrounding <>.
So  is the "class object" for the 
record type. I will probably use "method" and "class" a lot even
though it's not a proper object system.  You know what I mean.

Thanks, 
b.g.



At the top level, each report should create exactly one object of type
.  The  is the "container" for all your
report HTML information.  You can render it to an HTML string with
(gnc:html-document-render) or add some content to it with
(gnc:html-document-add-object!).

An  is basically a set of  that get
rendered in sequence when you call (gnc:html-document-render) at the
end of your report.  You can think of one  as a
block-level element in HTML, like a paragraph, a table, or a guppi
graph.  There are several different types:

   - text.  You can stick as much marked up text as you want in one
 text object; you can limit an  object to one paragraph
 or stick multiple paragraphs in it.  

 In order to preserve style information, you shouldn't use direct
 literal markup in your strings (though it doesn't really hurt
 anything, it is not seen by the style system so you can't
 influence the way tags are rendered after the fact).  There is a
 family of functions called gnc:html-markup-* that are shortcuts
 to most of the common HTML markup (, , , -).
 The markup functions can be composed and take any number of
 arguments; the arguments are rendered and concatenated to become
 the body of the body.

 You can also markup using ANY tag with (gnc:html-markup tag
 . body), which does the expected body by default (or
 something else entirely if you have the "tag" style set
 differently... more later) or (gnc:html-markup/attr tag attr
 . body), which puts the attribute string 'attr' inside the start
 tag: body.  If there are attributes for the tag
 specified as part of the current style, the attributes you
 specify will be appended to the style's attributes.

 gnc:html-markup puts an end tag after the body; you should use
 gnc:html-markup/no-end and gnc:html-markup/attr/no-end if you
 wish to force no end tag.  Don't do this unless HTML syntax
 forbids end tags, please.

 Here is a short but complete HTML document demonstrating how to
 create and render text: 

 (let ((doc (gnc:make-html-document))
   (txt (gnc:make-html-text)))
   (gnc:html-text-append! txt
 (gnc:html-markup-h2 "This is a header")
 (gnc:html-markup-p 
   "This is a paragraph of plain text with a "
   (gnc:html-markup-b "bold")
   " section in the middle."))
   (gnc:html-document-add-object! doc txt)
   (gnc:html-document-render doc))

 html-document-render returns a string:  

 "
  
  This is a header
  This is a paragraph of plain text with a 
  bold section in the middle.
  "

 Any literals, like strings or numbers, that you include in an
 html-text object get rendered according to the 
 in effect for their type, so please don't render them yourself
 (unless you really want to).  

 See the  section for more info, but as a rule of
 thumb strings will be interpreted literally with HTML special
 characters escaped for you (i.e. 

Re: Access Controls

[David Merrill]

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 record
> > exists in the transaction table, it is necessarily the same "original"
> > data.
> 
> What is the 'audit table'? How does it work?

Here are my notes. Perhaps I should choose another term, in light of
the accounting use.

I am very unsure about how to handle the uuids when creating new
records. My notes say that the uuid always follows the data, so an
edited record gets a new uuid. This is tremendous implications for the
client.


AUDITING


The database provides a complete audit trail of all changes to data. The audit
trail mechanism uses the "breadcrumb" approach. No financial data is ever
changed or deleted in the physical database. Instead, records that become
invalid are moved into an audit table, before their data is changed.

When a record is created, it is marked with the user's guid and a timestamp,
so we always know who created the record and when.

If a transaction record is changed or deleted, it is copied into its 
corresponding audit table (named the same as the regular table but appended
with "_audit"). The audit table has a few extra fields to hold audit 
information. These fields are:

new_guidCHAR(32)guid assigned to replacment record
change_type CHARindicates 'D'elete or 'U'pdate
change_dbuser_guid  CHAR(32)who made the change
change_timestampTIMESTAMP   when the change happened

If a record is deleted, it is copied into the audit table, the change_type field
is set to 'D', and the other fields are populated. For transactions, all related
splits are necessarily deleted also, so they are treated likewise. Then the
original record is deleted.

When a record is modified, the original record is copied into the
audit table, and change_type is set to "U" for update. change_timestamp and
change_dbuser_guid are populated. Then the original record is updated.

The guid which travels with the original data is left alone in all cases,
but there is no primary key on the guid in the audit table, so this isn't a
problem. The newly created record is given a brand new guid. A guid always
uniquely represents a state of the record.

Of course, all of this is handled completely by the db, and when the engine
requests records it gets a simple recordset of the active records. Only the
database knows that any of these audit records even exist, unless an admin
comes in via the backdoor of the db and browses the records.

FIXME: Which tables require an audit trail? All of them? Financial data only?


-- 
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

user roles

[David Merrill]

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 a single account)
- account data entry (add/delete/update records in an account)
- account monitoring (read-only access)


-- 
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

corporate structures

[David Merrill]

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 release.

-- 
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

To the cross roads I must go
To find a world unseen
Fear and wonder will I know,
And be a bridge between
-- To the Crossroads, Starhawk

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[linas]

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 necessarily the same "original"
> data.

Maybe we are using guid's for too many conflicting purposes? 

It seems that we need another identifier that says 
'this is the same record, even though we've been editing it.'


For example, don't splits store the guid's of thier parent accounts?
If you edit an account, and issue it a new guid, don't you have to
walk a zillion splits to update thier guid's as well ??

--linas


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[Derek Atkins]

<[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.  In particular, it's
still possible to deadlock in a few situations (I explained this in my
longer email).  There are also certain limitations that I need to
think through.  However, this code is completely generic with respect
to GnuCash.  It's a generic ONC-RPC transport type and you could use
it for (just about) any RPC program.  Indeed, my sample is currently
just a 'Hello World' client/server. :)

> Is there some sort of rpc-special-interest-group, with a mailing
> list or web page, that this would be a suitable submission for?

Good question.  I don't know of any.  However, I think that they
wouldn't be completely interested because this puts some extra
limitations on what you can/cannot do.  And some places are a bit
kludgy.  Again, see my long mail for a more "coherent" explanation.

-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: Access Controls

[Derek Atkins]

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 object has changed because the version
number has changed.

Notifications of changes are still possible.

-derek

Christopher Browne <[EMAIL PROTECTED]> writes:

> Yes, indeed, this seems an overly conflicted use of GUIDs.
> 
> I _thought_ the point of the exercise was for the GUID to represent
> a permanent unique identifier for an object.
> 
> If it changes, that seems to me to be a Bad Thing.
> 
> There _is_ a reasonable policy to use for this that seems rather
> a lot less abusive:
> 
> -> Generate a new GUID for each entry that gets added to the "audit log."
> 
> -> The audit log should _also_ include a reference to the "active"
>transaction's GUID, so that one may trace from audit log to the
>current version of the transaction, and, if there is an index on
>audit_log-oldGUID, from transactions to audit log.
> 
> Thus, the active transaction doesn't get a new GUID value all the time.
> 
> If there are processes out there that need to know when a particular
> transaction changes, it makes sense to have something analagous to the
> CORBA Notification or Event services rather than changing GUIDs all the
> time.

-- 
   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: Asynchronous, Bi-Directional ONC-RPC: status + input requested

[Derek Atkins]

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 you really need new data, you can
> get it whenever you want it.

This can be a hell of a lot of data.  If you haven't noticed, a data
refresh requires downloading ALL your data ALL the time (well, every
time you refresh).  Perhaps if you only have one transaction open this
isn't a big deal, except now you're downloading that transaction over
and over for potentially no reason at all.  It also means you now have
to go poll the server for changes, and Polling is Bad (TM).

> Tell me what practical problems this would pose for the user and/or
> the system. Increased network traffic? I'm not sure about that,
> because many, many users would never bother to refresh. Most real
> installations would have a single person accessing any given account
> at a time, and probably one person, period, with access to the data.
> Write access, anyway.

As I said, network traffic is an issue.  And users would HAVE to
refresh before they can commit.  The problem gets worse if you
actually do have multiple users writing data.

I can EASILY envision two people with write access: me and my wife.  I
can also easily envision both of us using it at the same time.  I
certainly can't guarantee that we wouldn't want to edit the same
account at the same time.

> It seems that you're designing a system to handle 100 clerks sitting
> at terminals typing away, and I don't think that's realistic. It
> certainly makes the system far more powerful and scaleable - I just
> think you're adding lots of complexity for little real-world gain.

No, I'm designing the system for TWO "clerks" sitting at terminals
typing away.  It just so happens that it will also scale to 100. ;) If
I wanted purely read-only (update-via-refresh) semantics, I'd build a
pure CGI interface and use Netscape as my client.  But that's not what
I want.  I want live data in a distributed system.  Perhaps I'm
over-engineering it a bit, but I like having live data.

> If you haven't noticed by now, I am very much a minimalist. Get the
> job done as simply as possible. And no simpler. :-)

And if you haven't noticed, I like designing for the long-haul, making
sure your design can withstand scaling beyond the immediate future.
Unfortunately I've seen too many systems designed, built, and
deployed, and only later have it determined that some of the basic
design assumptions were false.  This had the unforutnate consequence
of causing massing scaling problems (the system was being used far
more than ever anticipated, in ways never conceived by the original
designers).

I would certainly LIKE the system to scale to 100 clerks.  But I think
scaling to two would be good enough. :)

This really boils down to the fundamental question of whether clients
should have live data.  I feel that yes, they should.  Clearly you
feel that no, they shouldn't.  I suppose we must agree to disagree
here.  However I should point out that in my system your client just
wouldn't register for callbacks and you get your desired behavior.  In
your system, you cannot achieve what I want ;)

-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

Asynchronous, Bi-Directional ONC-RPC: status + input requested

[Derek Atkins]

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 in previous messages, I've been working on a
multiplexed ONC-RPC implementation that allows you to to provide
bi-directional call-reply semantics across a single (client-created)
TCP stream.  The goal was to create a means for a client to connect to
a server, make RPC requests, get RPC responses, and also enable the
server to make RPC requests (callbacks) to the connected client (maybe
even getting an RPC callback response, but maybe not).

The ONC RPC protocol definition allows such behavior, however the
standard implementation does not implement it.  The reasons are
obvious if you think about it.  Most RPCs are Synchronous calls (the
same is true of CORBA).  The standard RPC implementation makes the
call out to the network and then blocks waiting for the response.

A standard call (e.g. Split ** xaccQueryGetSplits(Query *)) would like
this would look like:

 Client  Server
   call (arg)-->
   blocksmakes local call()
  for reply  gets local results
 <- (repl) response

The call has a timeout (so your client doesn't hang forever).  You can
specify an Asynchronous call by setting an explicit timeout of zero.

As I said, the problem here is obvious: If you're sitting there in the
client waiting for a response, how do you handle an incoming callback?
A related problem is how do you make a client callback from within a
service call? (it's the same question posed from the other side).

 Client Server
   call (arg)>
  block makes local call.
 for reply  makes callback
<-(arg) call
proceses callback?  block, waiting for callback response
 response (repl) >
gets local results
 <- (repl) response
 
There a few approaches that we can take:

  1) Use Threads..  Assume you have a background thread whose job it
 is to read from the network and then "process" the incoming
 message.  You have one thread per side per connection.  In other
 words, the client would have one thread per server (normally 1),
 and the server would have one thread per client.

 A client writes out its request to the network and then
 blocks waiting for its response.  The background thread reads
 from the network connection, and will wakeup the client call
 thread when its reply arrives.  If an incoming message is a call
 request, the background thread calls out to the service dispatch
 to handle the call.

 This approach allows you to multiplex multiple requests and
 responses, but there is still a problem.  You see, a call request
 needs to block waiting for its response.  That's ok, except if
 you make a callback from a service, you wind up blocking the
 service (background) thread.  This means your background "reader"
 thread is now blocked waiting for someone to wake it up, however
 it's the thread that normally does the wakeup.  So you've got a
 deadlock.

 There are a number of solutions to this problem:

 a) Run each service call in its own thread.  However, this means
we are even more tightly tied to threads than before, and we
are 'forking' threads left and right for every call.  A bit
expensive in my opinion, but certainly an option.

 b) Require all callbacks to be purely asynchronous.  This implies
that a callback from a service never needs to block.

 c) Make sure you don't call back to your own client.  You can
successfully call another client, just not your own, because
each client has its own reader thread on the server.  You wont
necessarily deadlock calling out to another client.

 d) Don't allow callbacks from within a service call.  This is a
harse restriction, and means the server process needs some
other event-based model for calling back to clients.  Most
likely the main process thread would need to watch a variable
and then make callbacks when that variable changes.

 Unfortunately there is no way to really enforce b, c, or d.  An
 implementor may still shoot themselves in the foot.  However
 there is another option:

  2) Use a purely event-based model.  All calls are considered
 asynchronous.  There are no "replies."  This implies that there
 is no blocking of a call, becuase replies come in via callback
 'events' (i.e, a call from the other side).  The problem with
 this is that you cannot implement something like the existing
 xaccQueryGetSplits() function because you 

Re: Access Controls

[Derek Atkins]

<[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 one socket open for as long as possible.  It can be
torn down and rebuilt, however doing so would possibly lose session
state.

> I envision, for example, a gnucash client staying up for days or
> weeks, but the socket to the server going down, e.g. because some
> firewall or dslam router recycled.  Would I have to stop & restart
> the gnucash client, or just continue? What about events in that case?
> Do they get queued up in a pending queue, or simply discarded cause
> the client isn't listening?

In this case, the events would be discarded while the client was
"down" (as far as the server was concerned).  When the client
reconnected, it would have to revalidate it's data cache and setup new
callbacks.

> (the http world has trained us to think of socket connections as
> relatively fleeting, ephemeral things, and that's not bad; it just
> raises some interesting issues.)

It's not a world I completely buy.  The problem is that we're talking
about stateful sessions.  So, when do you throw out the state?  Or how
do you even define a "session"?  Obviously this is open to debate.  My
personal preference is to throw out the session state when the
connection goes away.  It also provides a clear definition of the
begining and ending of a session for both sides.  In addition, this
model still allows you to have a long-running client across multiple
'sessions'.

> --linas

-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: Access Controls

[linas]

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 days or
weeks, but the socket to the server going down, e.g. because some
firewall or dslam router recycled.  Would I have to stop & restart
the gnucash client, or just continue? What about events in that case?
Do they get queued up in a pending queue, or simply discarded cause
the client isn't listening?

(the http world has trained us to think of socket connections as
relatively fleeting, ephemeral things, and that's not bad; it just
raises some interesting issues.)

--linas

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[Derek Atkins]

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)
> - corporate administration (manage one set of books)
> - account administration (manage a single account)
> - account data entry (add/delete/update records in an account)

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 entries.

Perhaps we might want a "can perform these operations but commitment
requires the approval of someone else".  I.e., they can try to update
a record, but I need to approve the change before it is committed.

> - account monitoring (read-only access)

-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: user roles

[Derek Atkins]

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 guess this implies that the each user must have a login to the
database?

> I am allowing for an arbitrary number of "role" records to be
> defined, each of which can be assigned any set of permissions. Each
> user is then assigned one or more of these roles, and inherits all the
> permissions provided by any of them.

That sounds eminently reasonable to me.  Indeed, I think there might
be two sets of "roles" (mind if I call them groupings?).  First, you
can have a set of groupings that bunch together a set of permissions,
e.g.  read, write (which implies read), all (which implies read,
write, admin, etc.  Second, you can have a set of groupings which
define roles, e.g. sysadmin, financial-manager, entry-twit, etc.  The
former list is most likely pre-defined by the system.  The latter set
of groups is user-defined and allows users to build groups of
users. :)

Indeed, when I say  above, I really mean "name of user or name
of group".

But it sounds like we're on the same page.  Wonderful.

-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: Asynchronous, Bi-Directional ONC-RPC: status + input requested

[David Merrill]

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 web interface to the engine, and you
> > get new data by hitting refresh. If you really need new data, you can
> > get it whenever you want it.
> 
> This can be a hell of a lot of data.  If you haven't noticed, a data
> refresh requires downloading ALL your data ALL the time (well, every
> time you refresh).  Perhaps if you only have one transaction open this
> isn't a big deal, except now you're downloading that transaction over
> and over for potentially no reason at all.  It also means you now have
> to go poll the server for changes, and Polling is Bad (TM).
> 
> > Tell me what practical problems this would pose for the user and/or
> > the system. Increased network traffic? I'm not sure about that,
> > because many, many users would never bother to refresh. Most real
> > installations would have a single person accessing any given account
> > at a time, and probably one person, period, with access to the data.
> > Write access, anyway.
> 
> As I said, network traffic is an issue.  And users would HAVE to
> refresh before they can commit.  The problem gets worse if you
> actually do have multiple users writing data.
> 
> I can EASILY envision two people with write access: me and my wife.  I
> can also easily envision both of us using it at the same time.  I
> certainly can't guarantee that we wouldn't want to edit the same
> account at the same time.
> 
> > It seems that you're designing a system to handle 100 clerks sitting
> > at terminals typing away, and I don't think that's realistic. It
> > certainly makes the system far more powerful and scaleable - I just
> > think you're adding lots of complexity for little real-world gain.
> 
> No, I'm designing the system for TWO "clerks" sitting at terminals
> typing away.  It just so happens that it will also scale to 100. ;) If
> I wanted purely read-only (update-via-refresh) semantics, I'd build a
> pure CGI interface and use Netscape as my client.  But that's not what
> I want.  I want live data in a distributed system.  Perhaps I'm
> over-engineering it a bit, but I like having live data.
> 
> > If you haven't noticed by now, I am very much a minimalist. Get the
> > job done as simply as possible. And no simpler. :-)
> 
> And if you haven't noticed, I like designing for the long-haul, making
> sure your design can withstand scaling beyond the immediate future.
> Unfortunately I've seen too many systems designed, built, and
> deployed, and only later have it determined that some of the basic
> design assumptions were false.  This had the unforutnate consequence
> of causing massing scaling problems (the system was being used far
> more than ever anticipated, in ways never conceived by the original
> designers).
> 
> I would certainly LIKE the system to scale to 100 clerks.  But I think
> scaling to two would be good enough. :)
> 
> This really boils down to the fundamental question of whether clients
> should have live data.  I feel that yes, they should.  Clearly you
> feel that no, they shouldn't.  I suppose we must agree to disagree
> here.  However I should point out that in my system your client just
> wouldn't register for callbacks and you get your desired behavior.  In
> your system, you cannot achieve what I want ;)

You have just given me 3 good reasons for live updates: there *are*
likely to be simultaneous users even in small installations, you
*have* to refresh before you can do a commit, and therefore network
traffic *is* an issue. Fine. Sold me. Next issue. :-)

-- 
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

Three from the hall beneath the tree
Is, Was, and Shall Be
Come Wyrd Sisters swoop to the ground
Loosen the web that binds us down
Join with the hands of the Weavers Three
Is, Was, and Shall Be
-- Is, Was, and Shall Be, Beverly Frederick

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[Derek Atkins]

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/her to be able to change or even
> > worse delete entries.
> 
> I'm not convinced of the need for this. It sounds like one of those
> "would be nice" features programmers think up that users don't care
> about. Of course I know I could be completely wrong.
> 
> But a user could have separate permissions for their own data (data
> they added) and other folks' data. So s/he can edit a mistake s/he
> made, but can't change another user's records. I can't see any reason
> for preventing a user from editing data they put in in the first
> place.
> 
> And ownership does not change when somebody else makes an edit. If you
> created the record, you own it forever, at least in this context.
> 
> Does this address your concern adequately?

No.  I still think there are times when someone might have permission
to create an entry, but not delete it (even if they "own" it).  The
problem is that a malicious user could go and destroy a lot of work,
requiring a lot of time and effort to recover.  Whereas we can prevent
it in the first place with a little more work on our shoulders.

> Or if not made unnecessary, it is at least made less important. And it
> would be decidedly nontrivial to implement. I'm trying to keep things
> simple, remember? ;-)
> 
> This is another reason why I think separating add and delete/update
> permissions is not needed.

Being able to recover data is a good thing.  However, it would be nice
to not have to depend on spending time recovering data when
"unauthorized" changes are made.  I'd rather have the changes fail in
the first place (or perhaps be flaged with "unauthorized").

-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

[offtopic] marshalling

[linas]

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-of what we do with g-wrap, and its kind-of what's
behind one of the original early claims of gnome's ORBit: that with
orbit, a call on the same machine would be roughly as fast as an
ordinary subroutine call. (I don't know if they kept that promise).

Here's the question: if one writes a soap dtd/schema in the M$
framework, it will then auto-generate language bindings for several 
languages? (i.e. they treat the  soap dtd/schema as an IDL for 
all practical purposes? OR did they invent some new IDL language?)

--
I also gather that microsoft's strategic direction with .net is to
control the VM: they have thier one standard true VM, while the rest
of the world has to live with multiple incompatible VM's (i.e. the 
Java vm, the perl VM, the guile VM, ...)  

And, of course, the corrolary question: should I feel bad about this? 
Other than integrated tools, and backwards compatibility with visual
basic and java, what, exactly, does .net offer that I can't get
today?

--linas
 

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Asynchronous, Bi-Directional ONC-RPC: status + input requested

[Derek Atkins]

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 is nothing inherently wrong with clients blocking for calls.
The "problem" occurs when you try to implement callbacks.  Perhaps I
wasn't clear in my ramblings?

You need callbacks for Event Notification and data "liveness" in
distributed client caches.  Basically, when data changes on the server
you need an asynchronous callback to the client in order to inform
them that data has changed.  This is important when you have multiple
clients reading (and caching) data and someone making modifications.
If clients never cache data, then sure, you probably don't need this.

However, if clients are going to cache data, then you need some way to
'invalidate' the cached data.  One way (e.g. the NFS way) is to have
the client check with the server every time you want to use the data.
Another way (e.g. the AFS way) is to have the server notify the client
when cached data changes.  The latter mechanism is more
network-friendly, however it requires callbacks.

So, assuming we agree that callbacks are necessary, the question is
what limitations, if any, do you put on them or on our implementation
using the callbacks.  Another question is what dependencies do you
want to put on the server that would be making callbacks.  If we don't
care that we depend on, say, pthreads, and if we don't care that we
invoke a new thread for every service call, then quite honestly there
isn't a big problem (this was option 1a :) However, then the server
needs to be more threads-aware.  The alternatives are to limit what
callbacks can do, or change the RPC model.

-derek

PS: The "problem" is in my current implementation: when a service
request is called, the dispatch function is called from within the
background reader thread.  If that service call makes a blocking
request (callback), then the background reader thread becomes
deadlocked.  The deadlock occurs because it is waiting for the reader
thread (namely itself) to wake it up (which it obviously cannot do).

-- 
   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: user roles

[David Merrill]

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 what I've missed:
> > 
> > - system administration (manage entire system)
> > - corporate administration (manage one set of books)
> > - account administration (manage a single account)
> > - account data entry (add/delete/update records in an account)

- 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/her to be able to change or even
> worse delete entries.

I'm not convinced of the need for this. It sounds like one of those
"would be nice" features programmers think up that users don't care
about. Of course I know I could be completely wrong.

But a user could have separate permissions for their own data (data
they added) and other folks' data. So s/he can edit a mistake s/he
made, but can't change another user's records. I can't see any reason
for preventing a user from editing data they put in in the first
place.

And ownership does not change when somebody else makes an edit. If you
created the record, you own it forever, at least in this context.

Does this address your concern adequately?

> Perhaps we might want a "can perform these operations but commitment
> requires the approval of someone else".  I.e., they can try to update
> a record, but I need to approve the change before it is committed.

This seems to be made unnecessary by the audit trail and the ability
to undo changes, which will not be in initial release but probably the
next one. Of course, a halfway capable db administrator can do an undo
anyway; there just won't be any support for it in the client or engine
in the first release. The audit trail really minizes the risk to which
your data is exposed by a malicious or incompetent clerk.

Or if not made unnecessary, it is at least made less important. And it
would be decidedly nontrivial to implement. I'm trying to keep things
simple, remember? ;-)

This is another reason why I think separating add and delete/update
permissions is not needed.

-- 
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

By the Earth that is Her body
By the Air that is Her breath
By the Fire of Her bright spirit
By the Waters of Her living Womb,
The circle is cast.
-- Traditional Circle Casting


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[David Merrill]

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 without calling a manager for
> > approval. That is just not acceptable. And allowing a user to edit or
> > delete something they have just edited is not a security or data risk.
> > A malicious user would have very limited ability to cause damage.
> 
> I have no objections to that.

Cool.

> > Will transactions be saved immediately upon entry, or upon user
> > request? If upon request, we're fine because the user can do anything
> > they want up until they save their work. If it is saved immediately,
> > we need some way of determining whether or not the record is still
> > editable by that user, although they don't have edit permissions. I'm
> > open to suggestions!
> 
> I was under the impression that data was "saved" when the user hit
> "commit".

Good, that makes things easier - both on the client and on the server.
 
> > Okay, so the permissions are:
> > 
> > - System Administration (manage entire system)
> > - Corporate Administration (manage one set of books)
> > - Account Administration (manage a single account)
> > (includes the ability to reconcile the account)
> > - Account Data Management (manage all transactions in the account)
> > - Account Data Entry (add/delete/update your own records only)
> > - Restricted Data Entry (add permission only)
> > 
> > Now does *this* work for everybody, or are there further needs
> > unaddressed?
> 
> This works, but I think for simplicity you might want to just
> enumeratate the operations.  Instead of grouping access as you've
> done, you can have permissions like:
> 
>   administer
>   add
>   update
>   delete
>   reconcile?
>   chown?
> 
> Then you can apply these operation permissions to each object:
>   1) the database
>   2) a set of bookes
>   3) an account
>   4) a split or a transaction

Yep, that's what I'm planning.

> This implies that each object would have an accociated ACL, and each
> ACL would have a list of entries that look something like this:
> 
> 
> 
> This allows the greatest flexibility in terms of editing ACLs and
> controlling data access.

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 am allowing for an arbitrary number of "role" records to be
defined, each of which can be assigned any set of permissions. Each
user is then assigned one or more of these roles, and inherits all the
permissions provided by any of them.

-- 
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

Whenever you have need of anything,
Once in the month, and better when the moon is full,
You shall assemble in some secret place
And adore the spirit of Me
Who is Queen of all the Wise.
-- 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: user roles

[David Merrill]

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 entries, but I dont want him/her to be able to change or even
> > > worse delete entries.
> >
> >I'm not convinced of the need for this. It sounds like one of those
> >"would be nice" features programmers think up that users don't care
> >about. Of course I know I could be completely wrong.
> >
> >But a user could have separate permissions for their own data (data
> >they added) and other folks' data. So s/he can edit a mistake s/he
> >made, but can't change another user's records. I can't see any reason
> >for preventing a user from editing data they put in in the first
> >place.
> >
> >And ownership does not change when somebody else makes an edit. If you
> >created the record, you own it forever, at least in this context.
> >
> >Does this address your concern adequately?
> >
> > > Perhaps we might want a "can perform these operations but commitment
> > > requires the approval of someone else".  I.e., they can try to update
> > > a record, but I need to approve the change before it is committed.
> >
> >This seems to be made unnecessary by the audit trail and the ability
> >to undo changes, which will not be in initial release but probably the
> >next one.
> 
> In the "real world" business situation, there is often a requirement 
> for the ability to allow one person to make entries that are then 
> reviewed and approved by a superior. The act of approving the entries 
> would cause the "ownership" of those entries to be changed.
> 
> One useful technique in doing this is to associate the "ownership" 
> with a role rather than a person and permit certain individuals to 
> alter the ownership property.
> 
> Often the policy will require that this ability be data sensitive.

That would be great, but it's too ambitious for the first release. I
will make a note of it, though.

-- 
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: Asynchronous, Bi-Directional ONC-RPC: status + input requested

[David Merrill]

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 to notice
the blocking, it is a bug. K.I.S.S.

-- 
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: Access Controls

[linas]

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 as well ...

--linas

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[Eugene Tyurin]

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 what I've missed:
> > 
> > - system administration (manage entire system)
> > - corporate administration (manage one set of books)
> > - account administration (manage a single account)
> > - account data entry (add/delete/update records in an account)
> 
> 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 entries.

Now,  this is  the dark  forest we  get into  when we  start playing
"enterprise class" database-backed software.

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.

2. All database  entries (even  superceded ones) must  be associated
with the userid  and time of creation.   This way a user  can give a
date to the  program and obtain an exact snapshot  of the books.  

-- 
ET.


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[David Merrill]

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 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 a single account)
> > > - account data entry (add/delete/update records in an account)
> > 
> > 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 entries.
> 
> Now,  this is  the dark  forest we  get into  when we  start playing
> "enterprise class" database-backed software.
> 
> 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.
> 
> 2. All database  entries (even  superceded ones) must  be associated
> with the userid  and time of creation.   This way a user  can give a
> date to the  program and obtain an exact snapshot  of the books.  

Both of these are under design right now. See
http://www.lupercalia.net/gnc-db/ for all my documentation and
scripts.

-- 
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

To attempt an understanding of Muad'Dib without understanding his mortal
enemies, the Harkonnens, is to attempt seeing Truth without knowing Falsehood.
It is the attempt to see the Light without knowing Darkness. It cannot be.
-- from "Manual of Muad'Dib" by the Princess Irulan

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[linas]

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 for network services, does it have something analogous that
we're not aware of?  What's the recommended practice? Also, what
about Microsoft's .net?  Do they punt on this issue?  Are the .net
users SOL?

--linas


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[Al Snell]

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-special-interest-group, with a mailing
> list or web page, that this would be a suitable submission for?

Yep, the IETF have one - I'm a member. When Derek's work is reaching
fruition, I'll approach him about approaching them with it :-)

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

Audit Logging, User Roles

[Christopher Browne]

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 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 a single account)
> > > - account data entry (add/delete/update records in an account)
> > 
> > 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 entries.
> 
> Now,  this is  the dark  forest we  get into  when we  start playing
> "enterprise class" database-backed software.
> 
> 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.

Hmmm...  If an "entry" is superceded, then we're left with two entries:
a) The original one, which is, in effect, no longer valid, and to which
   nothing should, any longer, point.

b) The new one, superseding the original, to which everything should _now_
   point.

Unfortunately, this leaves us in danger of being backed into the corner
where changing an entry results in having to cascade changes to all the
database records that refer to the entry.

Which means that when this happens, we really _do_ need to substantively
change the original record.  

A sensible procedure would be for the primary key on the table to be
something like a GUID, but _not_ one that is actually used to reference
the transaction "publicly," only to establish a unique primary key.

We then have a _second_ field in the table that is the "public GUID."
When a record is created, a GUID is generated and put in that field.

We also have a _third_ field in the table that is the "original GUID."

Thus, we have, in such a table, fields:
  a) prGUID [private GUID] [primary key for the table; unique, not null]
  b) GUID [public GUID] [secondary index for the table; unique, nulls allowed]
  c) parentGUID [Parent GUID] [another index on the table; NOT unique, nulls forbidden]

When a record gets created, the sequence might be thus:
 -> Generate a new private GUID, put it in prGUID
 -> Generate a new GUID to be used publicly, put it in field GUID.
 -> Also put the second GUID in field parentGUID

When a record is superceded, the procedure might be thus:
 -> Generate a new private GUID, put it in prGUID for the _new_ record.
 -> Fill in the "rest of the new record."
 -> Set field GUID for the new record to have the GUID field value from
the previous version.
 -> Set field parentGUID to have the same value found in field GUID.

 -> For the record that is being superceded, set field GUID to null, so
that it disappears from the purview of the usual processes that will be
looking for non-null GUID values.

Alternatively, this could fold down to three fields:
a) prGUID  [as described above]
b) parentGUID [as described above]
c) status [Active/Superceded]

That cuts the size by one GUID field; might be worthwhile...

It's getting pretty hairy, to be sure.  The two extra fields have to be
associated with every table that we might want to keep logged.  Probably
as well as fields for:
d) UserID/SessionID of the one that last updated the record, and
e) Date/Time of the last update to the record.

By the way, what with us adding several more fields, and having all
sorts of excuses for there being nearly gratuitous additions of rows
to tables, there probably needs to be:
1) A mechanism for "archiving" obsolete information, so the DB doesn't
   grow too tremendously quickly, and
2) A mechanism for turning off logging for those situations where we
   plan to modify _hordes_ of records.

   At work, the guy I sit beside is periodically responsible for setting
   the SAP ERP system to stop doing audit logs, usually because there is
   some funky multiple-phase process running on the weekend that will
   be updating 40,000 employees several times in order to get all the
   changes into place.  Gratuitous logging can be a bad thing...

> 2. All database  entries (even  superceded ones) must  be associated
> with the userid  and time of creation.   This way a user  can give a
> date to the  program and obtain an exact snapshot  of the books.  

Another thought: Don't use userid, but rather _session_ ID.  Which might
well contain the user ID, mind you...

Consider that an automated process (such as "import the OFX file") might
not have ideal "user" information associated with it, particularly if
it took place late at night when users were snuggled a

Re: user roles

[David Merrill]

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 may give a secretary permission to
> > > add entries, but I dont want him/her to be able to change or even
> > > worse delete entries.
> > 
> > I'm not convinced of the need for this. It sounds like one of those
> > "would be nice" features programmers think up that users don't care
> > about. Of course I know I could be completely wrong.
> > 
> > But a user could have separate permissions for their own data (data
> > they added) and other folks' data. So s/he can edit a mistake s/he
> > made, but can't change another user's records. I can't see any reason
> > for preventing a user from editing data they put in in the first
> > place.
> > 
> > And ownership does not change when somebody else makes an edit. If you
> > created the record, you own it forever, at least in this context.
> > 
> > Does this address your concern adequately?
> 
> No.  I still think there are times when someone might have permission
> to create an entry, but not delete it (even if they "own" it).  The
> problem is that a malicious user could go and destroy a lot of work,
> requiring a lot of time and effort to recover.  Whereas we can prevent
> it in the first place with a little more work on our shoulders.

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 allowing a user to edit or
delete something they have just edited is not a security or data risk.
A malicious user would have very limited ability to cause damage.

Will transactions be saved immediately upon entry, or upon user
request? If upon request, we're fine because the user can do anything
they want up until they save their work. If it is saved immediately,
we need some way of determining whether or not the record is still
editable by that user, although they don't have edit permissions. I'm
open to suggestions!

> > Or if not made unnecessary, it is at least made less important. And it
> > would be decidedly nontrivial to implement. I'm trying to keep things
> > simple, remember? ;-)
> > 
> > This is another reason why I think separating add and delete/update
> > permissions is not needed.
> 
> Being able to recover data is a good thing.  However, it would be nice
> to not have to depend on spending time recovering data when
> "unauthorized" changes are made.  I'd rather have the changes fail in
> the first place (or perhaps be flaged with "unauthorized").

Okay, so the permissions are:

- System Administration (manage entire system)
- Corporate Administration (manage one set of books)
- Account Administration (manage a single account)
(includes the ability to reconcile the account)
- Account Data Management (manage all transactions in the account)
- Account Data Entry (add/delete/update your own records only)
- Restricted Data Entry (add permission only)

Now does *this* work for everybody, or are there further needs
unaddressed?

-- 
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

Under the full moon light we dance
Spirits dance, we dance
Joining hands, we dance
Joining souls rejoice!
-- Karen Beth

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[Tyson Dowd]

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?  What's the recommended practice? Also, what
> about Microsoft's .net?  Do they punt on this issue?  Are the .net
> users SOL?

Oops, forgot to mention that I don't know what SOL means, so I couldn't
answer that bit.

-- 
   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: [offtopic] marshalling

[Christopher Browne]

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 interoperation at the data
> > level on the same machine -- no marshalling required.  
> 
> Well, that's kind-of what we do with g-wrap, and its kind-of what's
> behind one of the original early claims of gnome's ORBit: that with
> orbit, a call on the same machine would be roughly as fast as an
> ordinary subroutine call. (I don't know if they kept that promise).
> 
> Here's the question: if one writes a soap dtd/schema in the M$
> framework, it will then auto-generate language bindings for several 
> languages? (i.e. they treat the  soap dtd/schema as an IDL for 
> all practical purposes? OR did they invent some new IDL language?)

None of the above.

What SOAP amounts to is a way of transmitting around messages in XML
form.

Which means that "marshalling" amounts to, on the transmission side,
generating a string/stream that is an XML document.  And on the
"receiver" side, "demarshalling" involves parsing an XML document
and extracting the tags.

See:
http://www.pythonware.com/products/soap/profile.htm
for more details.

The "clever marshalling" thing with ORBit most certainly Does Not
Apply _in spades_ to SOAP.
--
(concatenate 'string "cbbrowne" "@ntlug.org")

Rules of the Evil Overlord #193.  "If I am using the hero's girlfriend
as a  hostage and am holding her  at the point of  imminent death when
confronting the  hero, I will focus on  her and not him.  He won't try
anything with his true love held  hostage. On the other hand, the fact
that she has been weak, slow-witted, naive and generally useless up to
this point  has no bearing  on her actions  at the moment  of dramatic
climax."  

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[Christopher Browne]

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
> > record is generated. That means a new GUID as well. So if the record
> > exists in the transaction table, it is necessarily the same "original"
> > data.
> 
> Maybe we are using guid's for too many conflicting purposes? 
> 
> It seems that we need another identifier that says 
> 'this is the same record, even though we've been editing it.'
> 
> For example, don't splits store the guid's of thier parent accounts?
> If you edit an account, and issue it a new guid, don't you have to
> walk a zillion splits to update thier guid's as well ??

Yes, indeed, this seems an overly conflicted use of GUIDs.

I _thought_ the point of the exercise was for the GUID to represent
a permanent unique identifier for an object.

If it changes, that seems to me to be a Bad Thing.

There _is_ a reasonable policy to use for this that seems rather
a lot less abusive:

-> Generate a new GUID for each entry that gets added to the "audit log."

-> The audit log should _also_ include a reference to the "active"
   transaction's GUID, so that one may trace from audit log to the
   current version of the transaction, and, if there is an index on
   audit_log-oldGUID, from transactions to audit log.

Thus, the active transaction doesn't get a new GUID value all the time.

If there are processes out there that need to know when a particular
transaction changes, it makes sense to have something analagous to the
CORBA Notification or Event services rather than changing GUIDs all the
time.
--
(concatenate 'string "cbbrowne" "@ntlug.org")

Early to rise,
And early to bed,
Makes a man healthy
But socially dead. 

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: [offtopic] marshalling

[Tyson Dowd]

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 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-of what we do with g-wrap, and its kind-of what's
> > behind one of the original early claims of gnome's ORBit: that with
> > orbit, a call on the same machine would be roughly as fast as an
> > ordinary subroutine call. (I don't know if they kept that promise).
> > 
> > Here's the question: if one writes a soap dtd/schema in the M$
> > framework, it will then auto-generate language bindings for several 
> > languages? (i.e. they treat the  soap dtd/schema as an IDL for 
> > all practical purposes? OR did they invent some new IDL language?)
> 
> None of the above.

This is quite true.  One of MS's aims was "no more IDL".

> What SOAP amounts to is a way of transmitting around messages in XML
> form.
> 
> Which means that "marshalling" amounts to, on the transmission side,
> generating a string/stream that is an XML document.  And on the
> "receiver" side, "demarshalling" involves parsing an XML document
> and extracting the tags.

Yes.

> See:
> http://www.pythonware.com/products/soap/profile.htm
> for more details.
> 
> The "clever marshalling" thing with ORBit most certainly Does Not
> Apply _in spades_ to SOAP.

Yes -- to SOAP (by definition, wouldn't be using SOAP if you didn't go
to XML).  

However, this hides the intent of .NET, which I think is what Linas is
trying to ask about -- he just asked the question in the wrong direction.

If you write code in a language that targets .NET, you will
automatically get a SOAP/XML binding that can automatically generate a
WSDL (Web Services) description (that is, XML Schema).  But not vice
versa.  The Schema is a way of describing the call site to remote code,
but it is the call site itself that generates the schema.  In an IDL,
the IDL describes the call site to remote code AND generates the call
site, all you get to do is fill in the stuff between the { and }.

All you have to do to make a normal class method into a web method is
add a single "webmethod" attribute to the code (this is pretty
trivial to do).

Since .NET code all runs on the same VM, regardless of the source
language, you automatically get ORBit style "clever marshalling" (that
is, no marshalling at all) for local calls to other .NET code.
Only when you are making remote calls, or calls to some separate local
VM [1] will you go to SOAP.  (Some marshalling does take place when you
do interoperation with COM components).

The VM provides these services in much the same way that it provides
garbage collection or threads.  Everyone who runs in the VM can use
them.

(there will be more on this topic in a reply to your original post).

[1] If there is more than one VM on the machine, which may or may not
possible. 

-- 
   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: user roles

[John Hasler]

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 entries (even superceded ones) must be associated with
> the userid and time of creation.  This way a user can give a date to the
> program and obtain an exact snapshot of the books.

Put all entries into a single table (journal).  Never delete or alter any
of them.  Instead, add new correcting entries.  This eliminates the need
for an audit table.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Access Controls

[Tyson Dowd]

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
> 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?  What's the recommended practice? Also, what
> about Microsoft's .net?  Do they punt on this issue?  Are the .net
> users SOL?

Ok, we are starting to reach the edge of my understanding of SOAP, since
it has been largely driven by need.  I'm thinking of going out and
buying a book on the topic so I don't have to go out on such a limb.

However, my (possibly imperfect) understanding is:

With respect to SOAP, there's nothing builtin.  It's either provided by
your language binding or toolkit, or you roll your own in a pretty
similar way to how Derek has described.

http://www.extreme.indiana.edu/soap/events/report.html

gives a sample of doing events with SOAP.

SOAP is *just* message passing, an RPC in SOAP is two messages, one of
which happens to be called a "response".  This is what Derek Atkins
described as option 2. in his list of options -- everything is
asynchronous.

I will have to read up more to see what the recommended practice is. 
I suspect it is "whatever you are using now -- just use SOAP to pass
messages".  I think Derek's proposal would work just fine.


With respect to .NET, I'm a bit more knowledgable but it's still and
area that I have read about more than used (but given how new it is,
most people are in that boat).

.NET provides quite a bit of guidance and support when it comes to
asynchronous programming and events.  The event is a built-in primitive
in the type system of the .NET VM.  (I believe it was been built in to
COM+ which was the main technology behind "DNA", and it might have been
added to J++ too).  A class defines the events it can trigger, and you
can subscribe to those events by providing a handler for callbacks (they
call it a "delegate").  Depending on the language you are using to
generate .NET code this might look like an API, or you might have
special keyword support for it.

Their model is basically that the caller makes the decisions about
asynchronous calls, and the callee treats all calls as synchronous. 
The surrounding infrastructure puts wrappers around them to handle
the asynchronous stuff at the appropriate place.  Compilers targetting
.NET are expected to generate according to a particular convention.
SOAP/XML is (I think) completely orthogonal, this stuff happends
regardless.

There are also classes provided that do event logging and all sorts of
things.  I don't know much about them right now.

-- 
   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: Access Controls

[David Merrill]

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...
> > > 
> > > 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 necessarily the same "original"
> > > data.
> > 
> > Maybe we are using guid's for too many conflicting purposes? 
> > 
> > It seems that we need another identifier that says 
> > 'this is the same record, even though we've been editing it.'
> > 
> > For example, don't splits store the guid's of thier parent accounts?
> > If you edit an account, and issue it a new guid, don't you have to
> > walk a zillion splits to update thier guid's as well ??
> 
> Yes, indeed, this seems an overly conflicted use of GUIDs.

Yeah, I see your point. The idea was half-baked. Try this:

The guid never changes on the original record. If it is deleted, no
problemo - just move it to the audit table. If it is edited, copy it
to the audit table before changing the original. We could then have
lots of versions in the audit table, but they are all timestamped and
so we can recreate the audit trail easily. There's really no need to
even change the guid on them.

This brings back the problem I thought I had solved, which was
determining whether or not the record has changed already. Linas
suggested handling this by sending the original data along with the
updates when requesting a save. This would work, but seems kludgy. The
db then has to check, field by field, to see if it has changed.
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?

-- 
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 are the flow, and we are the ebb.
We are the weavers, we are the web.

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[David Merrill]

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 to the server in any format you
> > want, including the   you suggest.
> 
> I guess this implies that the each user must have a login to the
> database?

Correct. This is a requirement anyway to have complete, end-to-end
audit trails, and that's important.
 
> > I am allowing for an arbitrary number of "role" records to be
> > defined, each of which can be assigned any set of permissions. Each
> > user is then assigned one or more of these roles, and inherits all the
> > permissions provided by any of them.
> 
> That sounds eminently reasonable to me.  Indeed, I think there might
> be two sets of "roles" (mind if I call them groupings?).  First, you
> can have a set of groupings that bunch together a set of permissions,
> e.g.  read, write (which implies read), all (which implies read,
> write, admin, etc.  Second, you can have a set of groupings which
> define roles, e.g. sysadmin, financial-manager, entry-twit, etc.  The
> former list is most likely pre-defined by the system.  The latter set
> of groups is user-defined and allows users to build groups of
> users. :)

That's exactly it. I chose the term "role" because it implies with it
a business role, e.g., administrator, manager or data entry clerk. Now
who would like to take a stab at determining the default roles and
their default permissions? That would be a good exercise to fine tune
the set of permissions we configure.

I wonder how deeply these messages can nest before mutt throws up.
H, we may find out soon. ;-p


-- 
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

The great sea has set me in motion.
Set me adrift,
And I move as a weed in the river.
The arch of sky
And mightiness of storms
Encompasses me,
And I am left
Trembling with joy.

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[David Merrill]

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 preserves an audit
> trail but also simplifies the design.
> 
> > 2. All database entries (even superceded ones) must be associated with
> > the userid and time of creation.  This way a user can give a date to the
> > program and obtain an exact snapshot of the books.
> 
> Put all entries into a single table (journal).  Never delete or alter any
> of them.  Instead, add new correcting entries.  This eliminates the need
> for an audit table.

Sounds like an interesting idea. Can you elaborate?

-- 
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

May the circle be open but unbroken.
May the peace of the Lord and Lady go in our hearts.
We merry meet, and merry part, and merry meet again.
Blessed be.
-- Traditional Circle Opening

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: user roles

[Derek Atkins]

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 allowing a user to edit or
> delete something they have just edited is not a security or data risk.
> A malicious user would have very limited ability to cause damage.

I have no objections to that.

> Will transactions be saved immediately upon entry, or upon user
> request? If upon request, we're fine because the user can do anything
> they want up until they save their work. If it is saved immediately,
> we need some way of determining whether or not the record is still
> editable by that user, although they don't have edit permissions. I'm
> open to suggestions!

I was under the impression that data was "saved" when the user hit
"commit".

> Okay, so the permissions are:
> 
> - System Administration (manage entire system)
> - Corporate Administration (manage one set of books)
> - Account Administration (manage a single account)
>   (includes the ability to reconcile the account)
> - Account Data Management (manage all transactions in the account)
> - Account Data Entry (add/delete/update your own records only)
> - Restricted Data Entry (add permission only)
> 
> Now does *this* work for everybody, or are there further needs
> unaddressed?

This works, but I think for simplicity you might want to just
enumeratate the operations.  Instead of grouping access as you've
done, you can have permissions like:

administer
add
update
delete
reconcile?
chown?

Then you can apply these operation permissions to each object:
1) the database
2) a set of bookes
3) an account
4) a split or a transaction

This implies that each object would have an accociated ACL, and each
ACL would have a list of entries that look something like this:

  

This allows the greatest flexibility in terms of editing ACLs and
controlling data access.

-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: Access Controls

[linas]

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 notification.  Then all we do is
> build the network connection, add any transport-level encryption we
> want, and then apply the forward service on the server side, and the
> callback service on the client side.  All data is multiplexed across
> the single TCP connection.  It's kinda neat! :)
> 
> > For rpc or xml/soap, which don't have events, I don't know how to 'roll
> > our own', it seems complicated. Firewalls mess things up. I've never
> 
> See above; I've solved this problem (at least for ONC-RPC ;) -- the
> client always initiates connections to the server (so you can get
> through a NAT or firewall), and callbacks come back on that (single)
> TCP transport.

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-special-interest-group, with a mailing
list or web page, that this would be a suitable submission for?


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Asynchronous, Bi-Directional ONC-RPC: status + input requested

[David Merrill]

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 enough for the user to notice
> > the blocking, it is a bug. K.I.S.S.
> 
> There is nothing inherently wrong with clients blocking for calls.
> The "problem" occurs when you try to implement callbacks.  Perhaps I
> wasn't clear in my ramblings?

You were clear; I'm asking a slightly different question.

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 you really need new data, you can
get it whenever you want it.

Tell me what practical problems this would pose for the user and/or
the system. Increased network traffic? I'm not sure about that,
because many, many users would never bother to refresh. Most real
installations would have a single person accessing any given account
at a time, and probably one person, period, with access to the data.
Write access, anyway.

It seems that you're designing a system to handle 100 clerks sitting
at terminals typing away, and I don't think that's realistic. It
certainly makes the system far more powerful and scaleable - I just
think you're adding lots of complexity for little real-world gain.

If you haven't noticed by now, I am very much a minimalist. Get the
job done as simply as possible. And no simpler. :-)

-- 
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: user roles

[Richard Wackerbarth]

>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 entries.
>
>I'm not convinced of the need for this. It sounds like one of those
>"would be nice" features programmers think up that users don't care
>about. Of course I know I could be completely wrong.
>
>But a user could have separate permissions for their own data (data
>they added) and other folks' data. So s/he can edit a mistake s/he
>made, but can't change another user's records. I can't see any reason
>for preventing a user from editing data they put in in the first
>place.
>
>And ownership does not change when somebody else makes an edit. If you
>created the record, you own it forever, at least in this context.
>
>Does this address your concern adequately?
>
> > Perhaps we might want a "can perform these operations but commitment
> > requires the approval of someone else".  I.e., they can try to update
> > a record, but I need to approve the change before it is committed.
>
>This seems to be made unnecessary by the audit trail and the ability
>to undo changes, which will not be in initial release but probably the
>next one.

In the "real world" business situation, there is often a requirement 
for the ability to allow one person to make entries that are then 
reviewed and approved by a superior. The act of approving the entries 
would cause the "ownership" of those entries to be changed.

One useful technique in doing this is to associate the "ownership" 
with a role rather than a person and permit certain individuals to 
alter the ownership property.

Often the policy will require that this ability be data sensitive.


Richard Wackerbarth The Digital Dataplex
[EMAIL PROTECTED]8801 Camelia Ln
(512) 345-7941  Austin, TX 78759

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel