I am working on some code (at the moment separately to CoreLinux++) but would be interested in CoreLinux++'s team looking at it and critiqueing it at some point.
(Sourceforge project CommonC++)
Dan (Kinnison)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm posting this here as my e-mail is dodgy and whilst I can read - writing back is hard :(
I agree that the underlying principles described in your email are sound and flexible - however, as a programmer in a games company - (always pushed to produce code on schedule) - it is sometimes necessary to take a step back from the elegant and "perfect" solutions - to one which will "do" in order to fulfil requirements. Persistence in the sense you have addressed it - is well worth the approach you have taken, however my tack was from the "save-game-state" point of view - where my approach works. For my needs, the abstracted DBMS/Store/Cursor form was well over-engineered.
It is my concern that should you only provide the "elegant" solutions, people will be less inclined to use them, than if you also provide smaller - "quick&dirty" option. My Persistence engine is small, easily extensible I hope, and once my core classes are defined - will provide a simple base on which to build small programs (or games) needing persistence. The company I work for already uses a similar persistence engine in some very successful games - so it is "tried and tested" as it were.
Perhaps our projects are too far apart to work together - I am looking to produce a set of small - useful libraries which work together, whereas CoreLinux++ is looking for a catchall set of code.
Share and Enjoy
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I understand your concern correctly, people are more inclinded to use "quick and dirty" solutions.
I don't share your concern, I think that given a problem domain which is looking for many points of solution they will opt for the elegant approach.
I also think that there are many more things to consider than what you are indicating. As I posted in my e-mail, some things don't scale well. If you provide a class library for persistence and it goes to hell in a hand-basket when the data is greater than what memory can hold, your solution does not work in that problem domain.
In addition I don't understand your comment that CoreLinux++ is trying to be a "catchall set of code"???
The core will contain fundamental objects and patterns, external frameworks will build on those core constructs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My problem with the Elegant solution has always been ease of use.
I agree that given lots of needs, the most elegant solution is the best, however, I also have to say that sometimes a system where I only have to think about one or two variables, rather than balancing several - is much more preferable.
Perhaps I misunderstood you when you said that the user of the code would fill in the persistence framework as they need.
Will you be providing a standard implementation, say for savegames?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The CoreLinux++ framework (libcoreframework++) should include a Persistence Abstraction.
The CoreLinux++ framework will include at least one (1) persistence implementation.
I am working on some code (at the moment separately to CoreLinux++) but would be interested in CoreLinux++'s team looking at it and critiqueing it at some point.
(Sourceforge project CommonC++)
Dan (Kinnison)
I looked at the code and sent you an e-mail. I am not quite sure what type of comments you are looking for, such as style, flexibility, etc.
I'm posting this here as my e-mail is dodgy and whilst I can read - writing back is hard :(
I agree that the underlying principles described in your email are sound and flexible - however, as a programmer in a games company - (always pushed to produce code on schedule) - it is sometimes necessary to take a step back from the elegant and "perfect" solutions - to one which will "do" in order to fulfil requirements. Persistence in the sense you have addressed it - is well worth the approach you have taken, however my tack was from the "save-game-state" point of view - where my approach works. For my needs, the abstracted DBMS/Store/Cursor form was well over-engineered.
It is my concern that should you only provide the "elegant" solutions, people will be less inclined to use them, than if you also provide smaller - "quick&dirty" option. My Persistence engine is small, easily extensible I hope, and once my core classes are defined - will provide a simple base on which to build small programs (or games) needing persistence. The company I work for already uses a similar persistence engine in some very successful games - so it is "tried and tested" as it were.
Perhaps our projects are too far apart to work together - I am looking to produce a set of small - useful libraries which work together, whereas CoreLinux++ is looking for a catchall set of code.
Share and Enjoy
Daniel
If I understand your concern correctly, people are more inclinded to use "quick and dirty" solutions.
I don't share your concern, I think that given a problem domain which is looking for many points of solution they will opt for the elegant approach.
I also think that there are many more things to consider than what you are indicating. As I posted in my e-mail, some things don't scale well. If you provide a class library for persistence and it goes to hell in a hand-basket when the data is greater than what memory can hold, your solution does not work in that problem domain.
In addition I don't understand your comment that CoreLinux++ is trying to be a "catchall set of code"???
The core will contain fundamental objects and patterns, external frameworks will build on those core constructs.
My problem with the Elegant solution has always been ease of use.
I agree that given lots of needs, the most elegant solution is the best, however, I also have to say that sometimes a system where I only have to think about one or two variables, rather than balancing several - is much more preferable.
Perhaps I misunderstood you when you said that the user of the code would fill in the persistence framework as they need.
Will you be providing a standard implementation, say for savegames?
We will provide a persistence implementation with the initial framework.
What you have is fundementally what I had in mind, but we will base it on the use cases of Persistence minimals. So what it is, is TBD.
Sounds cool and funky :)
You might want to join our mailing list just to see the stream (although it is not the Grand Central of lists) of what will become the reqiurement.
The analysis for the persistence abstraction will consider the various potentials for implementation target stores.
The analysis will consider file based data storage.
The analysis will consider RDMBS data storage.
The analysis will consider OODBMS data storage.
The analysis will consider structured text data storage.
The analysis will consider the fact that many forms of storage work on keyed values.
The analysis will consider clustering of information.
The analysis will consider single phase and multi phase commit.
The analysis will consider rolling back read and write activity (rw used here for lack of domain terminology).
The analysis will consider remote data storage.
The analysis will consider internationalization of content potential.
The analysis will consider scalability.
The analysis will consider performance.
Persistence should provide abstractions for classes whose data is to be read or written.
Persistence should provide abstractions for the storage management interface.