DB4O in Sgine?

[Hicks, Matt]

Hey guys, I'm currently writing a logging system specific to Scala in Sgine for a work-related project.  I am planning on making the primary logging go to DB4O instead of text file logging but haven't decided whether to include the DB4OLogger in Sgine or if it should be kept as an external class.  I've been planning to use DB4O extensively in game development in the future anyway as I can use it for object serialization for a game server, so it raises the question: is it worthwhile to add the db4o dependency into Sgine or should it be an external extension module?  The JAR is about 2.4meg and that's really the extent of the necessary additions.

Long-term I intend to break Sgine up into a core and extensions but for now I'm thinking I should just put this into the project...anyone have any problem with that?

[Hans Häggström]

Well, serialization solutions seem like they start to go quite beyond
a 3D library - middleware frameworks might be best to keep as separate
libraries (I'm working on one myself at the moment, and have
tentatively selected MongoDB for persistence). 2.4Mb here and there
for things that are not necessarily used by the user starts to put on
unnecessary weight.

Why not simply use Java Logger? It's built into the Java libraries,
works out of the box, and can be redirected to any target the user
wants with custom handlers if need be. (I don't quite get the big
rush for 101 different logging frameworks myself, in particular when
they have almost identical API:s and integrate with each other).

Anyway, this is my initial reaction, I may be persuaded otherwise.

-- Hans

[Hicks, Matt]

Well, rather than a 3D library like jME the goal of Sgine is to be a 3D engine, and by nature the extent goes well beyond that of a library into encapsulating all the functionality to make up a game.  However, you are correct that this does push us to get larger and larger and that's a bad thing.  Before 1.0 beta my plan is to break the Sgine project up into modules to allow for people to pick and choose which parts they wish to use and very likely the database aspect will be one that many people choose not to utilize.  I would like to discuss Mongo with you further as I think we might be able to create an abstraction to store and retrieve from several backing databases (db4o, JPA, mongo, etc) thus removing the necessity to hard-code a choice up-front and further allow us to explore our different options for backing data.

As for logging in the past I've been a big fan of Java's logging infrastructure, but there is a great deal that can be painful in it and much that Scala can provide to add additional functionality to the logging architecture.  These are the primary reasons that led me to start writing a new logging framework.  I've checked in my initial work on it and you're welcome to give feedback if you don't think it's useful.

2010/7/20 Hans Häggström <hans.ha...@iki.fi>

[philip]

Doesn't DB40 have a GNU General Public License?

On Jul 21, 1:49 am, "Hicks, Matt" <mhi...@captiveimagination.com>
wrote:

[Hicks, Matt]

Ah, yes, you are correct...not really sure what problems that will cause.  Does any product that uses it have to also be GPL?

[Hans Häggström]

Yup.

LGPL libraries can be used by any code regardless of licensing, but
GPL requires any programs or libraries that use code or libraries
under GPL to also be GPL.

GPL is usually used for applications only, or for libraries with
commercial licensing options to reap some of the advantages of open
source while still keeping a business model based on licensing (which
seems to be the case with DB4O).

-- Hans

[Hicks, Matt]

Well that's problematic....so let's talk more about Mongo... :P

2010/7/21 Hans Häggström <hans.ha...@iki.fi>

[philip]

The only disagreement I have with MongoDB is single server durability
in case of failures or software crash:
http://blog.mongodb.org/post/381927266/what-about-durability
http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of

However, it seems they will get there eventually. Its nice that it
doesn't have a schema, you just put data in and you can scale to large
size with multiple machines and you can lots of good indexes to find
the data quickly.

On Jul 21, 9:27 pm, "Hicks, Matt" <mhi...@captiveimagination.com>
wrote:

> Well that's problematic....so let's talk more about Mongo... :P
>

> 2010/7/21 Hans Häggström <hans.haggst...@iki.fi>

>
>
>
> > Yup.
>
> > LGPL libraries can be used by any code regardless of licensing, but
> > GPL requires any programs or libraries that use code or libraries
> > under GPL to also be GPL.
>
> > GPL is usually used for applications only, or for libraries with
> > commercial licensing options to reap some of the advantages of open
> > source while still keeping a business model based on licensing (which
> > seems to be the case with DB4O).
>
> > -- Hans
>
> > On Wed, Jul 21, 2010 at 4:19 PM, Hicks, Matt
> > <mhi...@captiveimagination.com> wrote:
> > > Ah, yes, you are correct...not really sure what problems that will cause.
> > > Does any product that uses it have to also be GPL?
>

[Hans Häggström]

MongoDB also has a quite impressive performance, apparently due to
memory mapping the data files (this also brings in the requirement of
a 64 bit machine for databases larger than a few GB, because of the
direct memory mapping).

And they seem to be working on the multi-node aspect.

However, I'd suggest isolating the persistence from the rest of the
system, so that different approaches can be plugged in as needed (e.g.
many single player games would do perfectly fine with an in-memory
only implementation). We'd need to be able to serialize our data to a
JSON like structure thou (primitives, references, lists, and maps).

-- Hans

[Hicks, Matt]

I've spent some more time reading about GPL and it looks like the only problem we'll have is if we need to modify the DB4O source code.  I am considering making Sgine's org.sgine.db have a light-weight wrapper to plug in Neodatis or DB4O as they are both nearly identical in functionality except one is GPL and one is LGPL.  I will probably default to Neodatis and you can switch to DB4O if you want to take advantage of the additional functionality DB4O provides.

Thoughts?

My big problem with Mongo is that working with the data is not nearly as elegant as an object database.

2010/7/21 Hans Häggström <hans.ha...@iki.fi>

[philip]

I thought GPL was infectious if you link with the library, as in a
JAR. If you don't link with it, i.e. use it through some protocol
where its located outside of your program as a different programming
running, then its not infectious. I could be wrong, anyway, be
careful.

On Jul 22, 3:05 am, "Hicks, Matt" <mhi...@captiveimagination.com>
wrote:

> I've spent some more time reading about GPL and it looks like the only
> problem we'll have is if we need to modify the DB4O source code.  I am
> considering making Sgine's org.sgine.db have a light-weight wrapper to plug
> in Neodatis or DB4O as they are both nearly identical in functionality
> except one is GPL and one is LGPL.  I will probably default to Neodatis and
> you can switch to DB4O if you want to take advantage of the additional
> functionality DB4O provides.
>
> Thoughts?
>
> My big problem with Mongo is that working with the data is not nearly as
> elegant as an object database.
>

> 2010/7/21 Hans Häggström <hans.haggst...@iki.fi>

>
>
>
> > MongoDB also has a quite impressive performance, apparently due to
> > memory mapping the data files (this also brings in the requirement of
> > a 64 bit machine for databases larger than a few GB, because of the
> > direct memory mapping).
>
> > And they seem to be working on the multi-node aspect.
>
> > However, I'd suggest isolating the persistence from the rest of the
> > system, so that different approaches can be plugged in as needed (e.g.
> > many single player games would do perfectly fine with an in-memory
> > only implementation).  We'd need to be able to serialize our data to a
> > JSON like structure thou (primitives, references, lists, and maps).
>
> > -- Hans
>

> > On Wed, Jul 21, 2010 at 5:00 PM, philip <philip14...@gmail.com> wrote:
> > > The only disagreement I have with MongoDB is single server durability
> > > in case of failures or software crash:
> > >http://blog.mongodb.org/post/381927266/what-about-durability
>

> >http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeo...

[Hans Häggström]

At least that is the intent. If I recall correctly in GPL2 the JAR
linking was a loophole, because it is technically linked by the JVM,
not at compile time. But going down that route is against the spirit
of the license, and will just create bad blood.

Of course, you could write a generic DB interface in Sgine, and have
one GPL implementation in one extra jar using DB4O, and one BSD or
LGPL using something else. In that case it's up to the end users to
decide whether they want to use DB4O and make their program GPL, or a
BSD / LGPL database and use their own license.

-- Hans

[Hicks, Matt]

Well, I've read quite a bit about GPL3 and though it does not appear that it would be a problem unless we modify the source I think I'll finish abstracting the functionality and use Neodatis as the default implementation.  Neodatis seems very similar to DB4O and in many cases faster, but in the benchmarks the more you load it down the closer DB4O gets and eventually surpasses it.  Having the ability to choose Neodatis or DB4O would be a good thing I think and then Hans can write an implementation for MongoDB. :)

Another good reason not to make DB4O the default is because if you sell a game / application that uses it you have to purchase a commercial license...that would be a sucky dependency. :o

2010/7/26 Hans Häggström <hans.ha...@iki.fi>