> "da" == Derek Atkins <[EMAIL PROTECTED]> writes:
da> Locking is a challenging thing. You can't just depend on the
da> filestore to lock data; what happens if you have something
da> like looks like this:
[...]
da> What do you do? Presumably the DB can serialize (lock)
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> I don't see how the locking problem is a CM concern. I mean that you will
> have to solve the locking problem at the level of storing the new data before
> you need to worry about multilpe GUI's trying to read the file to see what
> needs to be cha
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> Are you thinking of `locking ' at the transaction level or account
> level. The example that comes to mind is: One person is reconciling
> last months records and someone else is entering this months
> transactions. As these modifications don't cl
Derek Atkins wrote:
> Phillip J Shelton <[EMAIL PROTECTED]> writes:
>
>
> > Would something like having user A have the only permissions to
> > change things if they opened the account first be a usefull first
> > pass. Or is that too simple?
>
> How does the UI know whether the user intends to m
Dave Peticolas <[EMAIL PROTECTED]> writes:
> I think the 'second pass' design addresses scalability to the point that
> is practical currently. It allows components to tell the CM they are
> watching specific engine objects. Filtering refreshes will be done in
> the CM, for now.
>
> For now, I'd
Derek Atkins writes:
> Dave Peticolas <[EMAIL PROTECTED]> writes:
>
> > I see your point, but to achieve real scalability will require much
> > more fine-grained information than just naming engine components you
> > want to watch. Consider that any time an account's name is changed,
> > every re
Dave Peticolas <[EMAIL PROTECTED]> writes:
> I see your point, but to achieve real scalability will require much
> more fine-grained information than just naming engine components you
> want to watch. Consider that any time an account's name is changed,
> every register everywhere needs to be upd
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> Hmm, this is the CVS merge problem isn't it?
Basically, yes.
> Would something like having user A have the only permissions to
> change things if they opened the account first be a usefull first
> pass. Or is that too simple?
How does the UI know
Derek Atkins wrote:
> Presumably the DB can serialize (lock) requests,
> so you don't get intersperced data. But you need more than that.
> In this particular case, User1 got to the DB first, so presumably
> user2 would receive a callback about the change to obj1. However,
> User2 already tried
Phillip J Shelton writes:
> Does the redraw update just a transaction or is the widget an
> account? If th e gui atom is an account and the changed data has
> been stored in the `account file' then the CM only has to have one
> call-back for the account no matter ho w many changes have been make
Dave Peticolas wrote:
> Derek Atkins writes:
>
> > Yes, your subsequent mail did explain that successfully, but you may
> > have a locking problem in the case of multiple GUIs touching the same
> > data.
>
> Probably, but that's just not a problem I'm trying to solve right now.
> You're welcome t
Derek Atkins writes:
> Perhaps this would add up to a LOT of callbacks, having to specify a
> callback for each transaction in each "open" account. In that sense,
> yes, it is unwieldy. However, I don't believe that it is "difficult
> to to characterize statically which engine objects need to b
Does the redraw update just a transaction or is the widget an account? If the
gui atom is an account and the changed data has been stored in the `account
file' then the CM only has to have one call-back for the account no matter how
many changes have been make to the transactions in the account?
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Derek Atkins writes:
> > James LewisMoss <[EMAIL PROTECTED]> writes:
> >
> > > So a change to data occurs. The engine has a registered listener in
> > > the GUI Component Manager that it calls to say something has changed.
> > > What happens then?
>
James LewisMoss writes:
> Dave> Yes, it seemed to me that 1) (with respect to the GUI) was a
> Dave> part of 2), so it made sense to me to combine them. But perhaps
> Dave> they should be separate things.
>
> I agree. Just seemed the email introduced what was going on as 1 when
> in fact it w
> On Wed, 29 Nov 2000 12:14:00 -0800, Dave Peticolas <[EMAIL PROTECTED]> said:
Dave> This is the introduction of the CM, yes. It is intended to
Dave> manage all major GUI components.
Dave> Close callbacks are commands -- "close yourself now".
OK. It doesn't seem quite like a callback, b
James LewisMoss writes:
>
> Hash table of changes. If gnc_suspend_gui_refresh isn't called the
> refresh callbacks get called for each change?
Yes.
> Dave> The last is used when doing very large amounts of changes, for
> Dave> which it would just be simpler to refresh everything:
>
> Dave
> On Wed, 29 Nov 2000 11:11:33 -0800, Dave Peticolas <[EMAIL PROTECTED]> said:
Dave> James LewisMoss writes:
>> > On Wed, 29 Nov 2000 01:59:22 -0800, Dave Peticolas
>> > <[EMAIL PROTECTED]> sa
>> id:
>>
Dave> Design --
>>
Dave> The refresh mechanism will be designed in two
Derek Atkins writes:
> James LewisMoss <[EMAIL PROTECTED]> writes:
>
> > So a change to data occurs. The engine has a registered listener in
> > the GUI Component Manager that it calls to say something has changed.
> > What happens then?
>
> I suspect that the GUI Component Manager then calls a
James LewisMoss writes:
> > On Wed, 29 Nov 2000 01:59:22 -0800, Dave Peticolas <[EMAIL PROTECTED]> sa
> id:
>
> Dave> Design --
>
> Dave> The refresh mechanism will be designed in two parts, an engine
> Dave> component and a GUI component. The engine component will be a
> Dave> simpl
James LewisMoss <[EMAIL PROTECTED]> writes:
> So a change to data occurs. The engine has a registered listener in
> the GUI Component Manager that it calls to say something has changed.
> What happens then?
I suspect that the GUI Component Manager then calls all the components
that registered a
> On Wed, 29 Nov 2000 01:59:22 -0800, Dave Peticolas <[EMAIL PROTECTED]> said:
Dave> Design --
Dave> The refresh mechanism will be designed in two parts, an engine
Dave> component and a GUI component. The engine component will be a
Dave> simple change callback mechanism, while the GU
22 matches
Mail list logo
