• Sergei Degtiarev (42/42) May 10 2016 I want to suggest an addition to standard library - persistent
• rikki cattermole (6/6) May 10 2016 First things first.
• Seb (5/6) May 15 2016 It seems like this review thread slipped under the radar. It is a
• H. S. Teoh via Digitalmars-d (20/26) May 22 2016 This PR has been stagnating in the queue for a *very* long time. I
• Basile B. (4/8) May 23 2016 "perpetual" is the name of that novel you'll show to your

Sergei Degtiarev <sdegtiarev yahoo.com> writes:

I want to suggest an addition to standard library - persistent 
object module. The idea is straightforward, if we use file mapped 
memory to store some data, the data may outlive the application 
and be kept until next application start, thus providing 
persistent and consistent storage between application runs. Two 
closest conceptions are obviously serialization and general 
shared memory, but there are several important moments which make 
a difference. It differs from serialization mainly by its 
efficiency and reliability, once the object in shared memory is 
created it might be accessed with almost same efficiency as any 
other in-memory value, moreover, it has all the chances to 
survive process crash or spontaneous stop as modification of any 
variable takes no time, unlike long serialization process. It 
also differs from general shared memory in its object-oriented 
approach, instead of separate allocation and initialization of 
the shared memory piece, we call ctor immediately returning 
initialized object with the difference, the object is placed into 
shared memory. The RAII concept is fully supported, the object is 
either created and initialized or created preserving its value if 
it did exist, (btw, this is why I had to create own shared memory 
functions instead of using existing std module). The module is 
also natural candidate for interprocess communications, but 
concurrency primitives are intentionally not included (except 
atomic creation), instead, various synchronizations may be built 
on top of it.
   Obviously, it might be used with value types only. The 
persistent object may contain either simple value or struct or 
static array, the file is either created or opened and extended 
if needed. In the last case, the object is initialized, or, in 
the case of array, only extended part is initialized. The 
existing part of the memory is kept as is, assuming it already 
contains initialized values. It might be also created as dynamic 
array, in this case the length is derived from the file size, and 
the file must exist.
The code is here: 
https://github.com/D-Programming-Language/phobos/pull/3625 , 
please see unittest section for numerous usage examples.
   I used the conception for several years (C++, fast and reliable 
transaction servers), and it proved to be very useful for such a 
kind of applications. The module is placed to review queue for 
voting and discussion. I will be happy to hear your opinion and 
suggestions.

rikki cattermole <rikki cattermole.co.nz> writes:

First things first.

No walls of text please.
White space is a requirement for good design and in this case communication.

As said on PR, make it into a dub package and let it prove itself.
Right now for what it /could/ do and what it does, doesn't quite match 
up. Show it works in real world, then lets talk.

Seb <seb wilzba.ch> writes:

On Wednesday, 11 May 2016 at 01:25:39 UTC, Sergei Degtiarev wrote:
 [...]

It seems like this review thread slipped under the radar. It is a 
proposal to have persistent (binary) serialization for objects to 
files.
Please have a look at the PR and state your opinion ;-)

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Sun, May 15, 2016 at 09:27:55AM +0000, Seb via Digitalmars-d wrote:
 On Wednesday, 11 May 2016 at 01:25:39 UTC, Sergei Degtiarev wrote:
 [...]

 
 It seems like this review thread slipped under the radar. It is a
 proposal to have persistent (binary) serialization for objects to
 files.  Please have a look at the PR and state your opinion ;-)

This PR has been stagnating in the queue for a *very* long time.  I
can't speak for others, but personally, as a Phobos reviewer, I find it
very daunting to review such a large PR adding a major new feature that
hasn't gone through community peer review or discussion.  This is
perhaps one reason for why nobody has paid attention to it, or rather,
nobody has dared to do anything about it yet. No one wants to take
responsibility for merging a major new feature that's not yet proven, or
with a design and/or API that hasn't been shown to work well in the
field. (It may actually already be the best API, but without actual user
feedback proving this, it's hard to be sure.)

So I think what somebody has already suggested is the best way to go:
make it a dub package, and let people actually use it, get feedback,
prove it in the field first. Once it's proven, and design issues and API
issues are ironed out based on feedback from actual users, then resubmit
it to Phobos and perhaps we'll get a better response then.

Hope this helps.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

Basile B. <b2.temp gmx.com> writes:

On Wednesday, 11 May 2016 at 01:25:39 UTC, Sergei Degtiarev wrote:
 I want to suggest an addition to standard library
 [...]
 The code is here: 
 https://github.com/D-Programming-Language/phobos/pull/3625 ,

"perpetual" is the name of that novel you'll show to your 
literature teacher at Yale, but definitevely not the name of a 
Phobos module ;)