Client--Server Implementation Model.

[Rishikesh Shukla]

Hi,

I am using GNU cash since last 6 month for my personal use. I like it very
well.

Now, I decided to put it in my business. So instead on putting to every
desktop which will be a local data, and need extra effort to collect and
analysis.

So i decided to put it in Client--server model so that every department will
have access to application using the web interface.

Do anybody have any idea how to implement it , how the register interface
can be converted to web page etc. How to diffrentiate the server logic and
client logic components.
--
Thanks & Regards
Rishikesh Shukla
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[Josh Sled]

thanks for your reply.

Please make sure to include gnucash-***@gnucash.org on all replies,
using your mailer's Reply To All option.

So you mean to say that right now its not possible to implement it but in near future this may be possible as developers has only has a codebase for desktop model.

It's always *possible* to implement, but it would take a lot of work.
Nothing this dramatic will change in the "near" future.

There is not currently any momentum to move gnucash in that direction,
though it is open-source software, all is takes is someone(s) interested
to do the work.

[Josh Sled]

Suppose, If i want to take charge of this change is it possible. If yes how can i do so. To whom i should contact.

You don't need to contact anyone in particular, up front. You should
start reading the source, proposing and making changes, and submitting
them for review. You'll want to join gnucash-***@gnucash.org
regarding development discussion.

[Josh Sled]

Post by Rishikesh Shukla
I am using GNU cash since last 6 month for my personal use. I like it very
well.
Now, I decided to put it in my business. So instead on putting to every
desktop which will be a local data, and need extra effort to collect and
analysis.
So i decided to put it in Client--server model so that every department will
have access to application using the web interface.
Do anybody have any idea how to implement it , how the register interface
can be converted to web page etc. How to diffrentiate the server logic and
client logic components.

With a lot of effort.

Your question is very open-ended; what are you asking, specifically?

The core gnucash engine could be adapted to a different application
model and user interface, sure. There is, unfortunately, a lot of
application logic that's too close to the UI code, e.g., in button-press
handlers. So that would need to be factored out.

I'd not try to salvage anything from the existing register ui
abstraction code, especially considering that it's already been
re-written even for a normal desktop app model, let alone a
web-request/response model.

I'd say there's many person-years of effort to get where you want
From the current gnucash codebase.

(I'd argue it is less work to properly re-build gnucash using modern
toolkits/frameworks and techniques.)

[Klaus Dahlke]

On Tue, 24 Nov 2009 13:41:03 -0500
...

Post by Josh Sled

Post by Rishikesh Shukla
So i decided to put it in Client--server model so that every department will
have access to application using the web interface.

....

Post by Josh Sled
With a lot of effort.
Your question is very open-ended; what are you asking, specifically?
The core gnucash engine could be adapted to a different application
model and user interface, sure. There is, unfortunately, a lot of
application logic that's too close to the UI code, e.g., in button-press
handlers. So that would need to be factored out.

Hi John,
quick question: do you know to what extend gnucash 2.3x/2.4 will be able to handle concurrent users when using gnucash with a database, e.g. postgresql? The gnucash installation on every PC would still be required, but all users would access the same data store.

Thanks,
Klaus
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[Josh Sled]

Post by Klaus Dahlke
On Tue, 24 Nov 2009 13:41:03 -0500
...

Post by Josh Sled

Post by Rishikesh Shukla
So i decided to put it in Client--server model so that every department will
have access to application using the web interface.

....

Post by Josh Sled
With a lot of effort.
Your question is very open-ended; what are you asking, specifically?
The core gnucash engine could be adapted to a different application
model and user interface, sure. There is, unfortunately, a lot of
application logic that's too close to the UI code, e.g., in button-press
handlers. So that would need to be factored out.

Hi John,
quick question: do you know to what extend gnucash 2.3x/2.4 will be able to handle concurrent users when using gnucash with a database, e.g. postgresql? The gnucash installation on every PC would still be required, but all users would access the same data store.

AIUI, there is no concurrent-multi-user support in 2.3.x/2.4. The
application still believes it has an exclusive view of the data, and is
thus not setup to re-query data at each view step, or to synchronize
with other application instances or via the database itself. I'm not
actively following gnucash development at present, so I might be out of
date, but I don't believe I am.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[Phil Longstaff]

2.3.x/2.4 will not support simultaneous access by more than one user.




________________________________
From: Klaus Dahlke <***@gmx.de>
To: Josh Sled <***@asynchronous.org>
Cc: gnucash-***@gnucash.org
Sent: Thu, November 26, 2009 3:23:55 PM
Subject: Re: Client--Server Implementation Model.

On Tue, 24 Nov 2009 13:41:03 -0500
....

Post by Josh Sled

Post by Rishikesh Shukla
So i decided to put it in Client--server model so that every department will
have access to application using the web interface.

.....

Post by Josh Sled
With a lot of effort.
Your question is very open-ended; what are you asking, specifically?
The core gnucash engine could be adapted to a different application
model and user interface, sure. There is, unfortunately, a lot of
application logic that's too close to the UI code, e.g., in button-press
handlers. So that would need to be factored out.

Hi John,
quick question: do you know to what extend gnucash 2.3x/2.4 will be able to handle concurrent users when using gnucash with a database, e.g. postgresql? The gnucash installation on every PC would still be required, but all users would access the same data store.

Thanks,
Klaus
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[Mike or Penny Novack]

I'm going to jump in here.

Need to first take a closer look at the "business need" before jumping
to "simultaneous access". The latter would "solve" the perceived need
but in a way that may not be really appropriate. Let me explain.

As businesses grow larger, transaction handling tends to become
specialized. Might have an "accounts receivable" clerk who handles those
transactions, sales clerks who enter that kind of transactions, etc.
Normally you DON'T want people to be able to enter transactions of a
sort not their area of responsibility, though of course a single person
might be wearing more than one of these "hats". Using "simultaneous
multiple access" would allow everybody to enter their assigned sorts of
transactions to the main books BUT it would also permit them to enter
unauthorized sorts of transactions.

In really large systems this is handled by "feeds" to "general ledger".
That might be the model we should consider. Not multiple simultaneous
access to the main books but some way by which data might be moved from
subsidiary (specialized) books to the main books and THAT doesn't
require simultaneous access as can be a "batch" process. And yes, right
now Gnucash would support "subsidiary books" (books that represent only
a portion of the business). What we don't have is any way to automate
"feeds" and transfers between these books. All well and good to have
that a manual process when you are talking about once a month
transactions between "petty cash" and "general ledger" with likely only
a few accounts affected. Another thing were that A/R to general ledger
on a daily basis with scads of customer accounts involved.

Understand what I am saying? Were I the owner of a medium size business
I probably wouldn't want the employees entering A/R or sales
transactions to be able to even SEE the main books. Just their part of them.

Michael D. Novack
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[Rishikesh Shukla]

Hi Mike,

Absolutely agreed with your point mike, even i was thinking of the same
thing. system should be audit-able and should have authorization.

So their must be one more module, called as authorization module, where you
can authorize one or more account to one or more people concerned with that
account and should be able to add, delete or modify the transactions. to
test it around we can apply this into desktop version also. I hope you
agree with me.

Dear JOSH:
======

Here i need your help, you sounds like a coding guy, and believe that
earlier you were actively involved writing codes. Well i have gone through
the link that you provided, But i could not found any of the page which
provides the data flow digram and ER Digram as well. so can you provide any
such docs or links.

Secondly, i putting this mail to whole Development group also. As i could
not find any listing of the groups that handles the different modules, since
it has been mentioned in the docs at the beginning itself which shows
the requirement of the modularization.


On Fri, Nov 27, 2009 at 6:49 AM, Mike or Penny Novack <

Post by Mike or Penny Novack
I'm going to jump in here.
Need to first take a closer look at the "business need" before jumping to
"simultaneous access". The latter would "solve" the perceived need but in a
way that may not be really appropriate. Let me explain.
As businesses grow larger, transaction handling tends to become
specialized. Might have an "accounts receivable" clerk who handles those
transactions, sales clerks who enter that kind of transactions, etc.
Normally you DON'T want people to be able to enter transactions of a sort
not their area of responsibility, though of course a single person might be
wearing more than one of these "hats". Using "simultaneous multiple access"
would allow everybody to enter their assigned sorts of transactions to the
main books BUT it would also permit them to enter unauthorized sorts of
transactions.
In really large systems this is handled by "feeds" to "general ledger".
That might be the model we should consider. Not multiple simultaneous access
to the main books but some way by which data might be moved from subsidiary
(specialized) books to the main books and THAT doesn't require simultaneous
access as can be a "batch" process. And yes, right now Gnucash would support
"subsidiary books" (books that represent only a portion of the business).
What we don't have is any way to automate "feeds" and transfers between
these books. All well and good to have that a manual process when you are
talking about once a month transactions between "petty cash" and "general
ledger" with likely only a few accounts affected. Another thing were that
A/R to general ledger on a daily basis with scads of customer accounts
involved.
Understand what I am saying? Were I the owner of a medium size business I
probably wouldn't want the employees entering A/R or sales transactions to
be able to even SEE the main books. Just their part of them.
Michael D. Novack
_______________________________________________
gnucash-user mailing list
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

--
Thanks & Regards
Rishikesh Shukla
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[Derek Atkins]

Hi,

Post by Mike or Penny Novack
Understand what I am saying? Were I the owner of a medium size
business I probably wouldn't want the employees entering A/R or sales
transactions to be able to even SEE the main books. Just their part of them.

Luckily we're not targeting businesses that large, so it's not a
problem. Once you're big enough to need more than one person entering
data into GnuCash, then you've outgrown GnuCash and should move onto
something more enterprise-friendly.

:-)

Post by Mike or Penny Novack
Michael D. Novack
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

-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
***@MIT.EDU PGP key available
_______________________________________________
gnucash-user mailing list
gnucash-***@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.