Op maandag 5 november 2018 20:16:04 CET schreef Craig Arno: > Geert, > > I just subscribed to the gnucash-devel mailing list. Where do I find > the list so I can find and respond to your message? I also need to > respond to Phil's message, in gnucash-devel. > > Short answer, no we do not have different ideas. I need to help you > understand my answer. Looks like Phil is sharing the same confusion as > you, so must have been my wording. I'd be happy to straighten this out > in gnucash-devel as soon as I can figure out how to get there, and spare > all the good users here from technobabble. > > Craig
You have found us :) Just reply to this e-mail message (use reply-to-all or reply-to-list in your mail client) and your answer will appear on gnucash-devel. Regards, Geert > > On 11/5/2018 1:49 AM, Geert Janssens wrote: > > Op maandag 5 november 2018 08:36:25 CET schreef craigarno: > >> Geert Janssens-4 wrote > >> > >>> Op zondag 4 november 2018 14:49:22 CET schreef craigarno: > >>>> Geert Janssens-4 wrote > >>> > >>> Whether it can work depends on > >>> whether the db layer we rely on has a notification mechanism for db > >>> changes we > >>> can hook into. The current db layer is provided by libdbi, which is not > >>> managed by the gnucash team and I haven't looked into this yet. > >> > >> If your call to libdbi is in the same thread and is a blocking call for > >> synchronous operation, then there shouldn't be a problem with updating > >> views after successful return from the libdbi call. Otherwise you may > >> have to look for semaphors to signal. > > > > This discussion really belongs on gnucash-devel. It's way to technical for > > the gnucash-user list. So I have moved it, please follow up on the > > gnucash-devel list. > > > > > > It looks like we are having a different idea of the network model gnucash > > will use. I'm getting the feeling your idea is that gnucash will turn > > into a client-server model, with the server part running on a server and > > a client interacting with this server. This is not the current design > > idea. > > > > The current plan is to have a desktop application that can connect to a > > database using database semantics (row level locking, ACID support). But > > there will be no gnucash server component as such. That database can be > > accessible over the network from different gnucash programs installed on > > different computers (and ideally devices). But that's where our current > > plan ends. And in this design I don't think there's an easy way to manage > > coordinated view updating across devices. I don't think you can have for > > example mysql signal changes to a client application (though I may be > > mistaken). So while the design will allow concurrent db access and > > modification, it will not allow keeping views in sync without active db > > polling. > > > > But perhaps if we get to the point where the core functionality is > > separated in it's own library, it should at least be easier for someone > > to write a client server system on top of that. > > > > Regards, > > > > Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
