Sorry to have interrupted ... I just remember that folks have moved from OmniBase to GemStone in the past for "performance reasons" and understand that those aren't the only reasons for having an OmniBase replacement ...
Dale On Mon, Aug 8, 2022 at 10:22 AM Yanni Chiu <yannix...@gmail.com> wrote: > Dale, > > It’s not about inventing a “database”, it’s a requirement to persist data > beyond image start/stop, along with intangibles like having the full source > code to tune for individual requirements. In my case the top (desired) > requirements are single directory or file per user (scaling), and no > additional server process(es) to be monitored for failure mode. > > Yanni > > On Mon, Aug 8, 2022 at 12:44 PM Dale Henrichs < > dale.henri...@gemtalksystems.com> wrote: > >> Norbert, >> Before you go off and invent a data base, you might take a look at >> GemStone and RemoteServiceReplication[1] ... >> >> Dale >> >> [1] https://github.com/GemTalk/RemoteServiceReplication >> >> On Mon, Aug 8, 2022 at 6:19 AM Norbert Hartl <norb...@hartl.name> wrote: >> >>> To all Omnibase and Monibase users. >>> >>> It turned out that neither of those are open source. The author of the >>> database contacted me clarifying the situation that he has the copyright >>> and never released something open source. This means that I will remove the >>> Omnibase repositories in few weeks from >>> >>> https://github.com/ApptiveGrid/MoniBase >>> >>> and >>> >>> https://github.com/pharo-nosql/OmniBase >>> >>> I'm very sorry about that but someone just took the code 9 years before, >>> copied it on github and put illegally an MIT license to the repository. We >>> only want free software in our repositories and hence the above will go >>> away. >>> >>> As we see it essential to have a good OO database in pharo we will see >>> how much effort it will be build a small and simple OO database that can >>> replace Omnibase. >>> >>> regards, >>> >>> Norbert >>> >>
