Quoting Daniel Espinosa <[EMAIL PROTECTED]>:
> I'm trying to question in the best way, with out injury to any, the GC
> architecture and try to HELP to have a better one.
The steps towards a better architecture are:
1) Convert QOF to use GObject natively instead of being GObject-like
2) Using the same QOF APIs, try to use GDA natively inside QOF
3) Consider moving more information into QOF.
However, in the short term, major architectural changes aren't on the table.
>> > Using a GdaDataModel or a GdaQuery, you can directly modify the data
>> > in the DataBase using a begin/commit transaction (usefull in a
>> > multiuser enviroment), of course this could fix the *autosave* future
>> > request becouse you can edit a transaction and when saved it wil be
>> > automaticaly commit to the server/database.
>>
>> You're missing a fundamental architectural design of QOF and GnuCash.
>> Please go study QOF and then come back here.
>
> I don't missing that, I have studied the QOF enough to know that is a
> GObject like implementation with a kind of GInterface, where you have
> to implement the methods in order to do the work like (init, dispouse,
> begin transaction, commit, roll back, and so).
This is true, QOF is gobject-like....
> If QOF have a GObject like architecture, may you can create objects
> where you can have methods for the GC to make his work, and allow any
> to derive from them to implement a new characteristics, even if the
> Backend have a GInterface (it has) you can implement the it in order
> to create a new back end a a clear way (I know this way in on the
> QOF's documentation); GDA has this kind of architecture in order to
> allow new Providers (any) implement the API and allow to be used
> inside a GDA app.
Yes, but it's still just the backend.. The front end isn't changing.
GnuCash is still buffering the data (through QOF). QOF is just a
framework; the objects themselves are still cached in RAM, and implemented
by GnuCash. QOF just provides the framework to hold it all together
and Query over those objects.
> I see you don't want to help any one that doesn't have a previous
> knowlege about QOF, even if he/she have some knowlege about GObject
> architecture; I know that may you haven't time enough but I haven't
> time to learn QOF, I prefer to learn more about GObject.
It's not that I don't want to help, but I want to help make forward
progress in small steps. Your questions read to me the same as someone
asking:
* Why can't I rewrite GnuCash in C++?
* Why can't change GnuCash to use WxWindows?
* Why can't we write reports in python?
* Why isn't GnuCash a client/server Web Application?
Hundreds of man-years of effort have gone into the current GnuCash code.
It's irresponsible to just throw that all away. Making fundamental
changes to the way to application works is detremental to the process.
This thread started as a SQL BACKEND. That's a very limited scope,
and I'm happy helping someone (you, Phil, Matthew, or anyone else)
to make progress on a SQL Backend. That backend can use GDA. Fine.
No problem. But discussions of fundamental architectural shifts of
the gnucash application? Sorry, not interested.
>> Incremental changes are good.
>
> Is good to hear you "incremental changes are good", but I can see you
> can't support to hear any discution about that.
But you're not talking about that.. You're talking about fundamental
changes. Let's take small steps here!
> Sorry but I don't know who you are, are you the mantainer and have you
> the last word about GnuCash?
Pretty much, yes. I'm the longest-standing core developer. I'm a major
feature contributor. I'm an active maintainer. I'm "customer support".
And I'm the hosting/service provider. So, yes, what I say tends to carry
a LOT of weight.
But as you can see from other email, I'm open to listen. Chris convinced me
that we should look forward to GDA-2 (through 1.99) instead of keeping
with 1.9
> Is QOF the realy unique way to solve the GC's objectives? Can't be
> moved out or GC must use it in order to work with databases?
I think you're asking, "is QOF the ONLY way to solve GC's objectives?"
Of course not. KMyMoney doesn't use QOF; it solves the problem differently.
However, can QOF get removed from GnuCash? No. QOF is a fundamental
GnuCash architecture.
Now, could QOF get changed over time to be more like a GDA Wrapper?
Maybe. But that's not something I think should be discussed in the
same conversation as a SQL Backend.
I'm trying to keep the conversation focused on the task at hand instead
of looking towards projects that are probably 5 years out. And yes,
realistically I see what you propose as something that wouldn't happen
for five years.
> I don't think so.
-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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
