[dozzie]

> With GoshawkDB it really is up to the client as to what API you offer.

So GoshawkDB is not an object database and apparently never will. That's OK, but don't call it object store. It's misleading, as it uses already-established term for something different, which also already has a name.

[msackman]

So that I understand, what is the definition of object store?

[dozzie]

https://en.wikipedia.org/wiki/Object_database

Mind you, in several programming languages objects can have instance-specific methods (Ruby and Python being notable examples). This alone makes object more than merely a sum of a predefined structure having data fields and (also predefined) schema having functions to operate on those fields.

[msackman]

Thanks for the link. Whilst I'm not arguing with your point, I believe I've never used the term "object database" to describe GoshawkDB, only "object store". I guess I'm struggling to find a more accurate term than "object store" to describe GoshawkDB. I don't like "document store", as to me "document" tends to be something human readable.

[dozzie]

I understand your reluctance for using term "document". I don't like it much either when it comes to JSON entities, but I can't find any better term, much less a widely used one.

Look at the matter this way: CouchDB, MongoDB, and ElasticSearch, all use the term "document" to describe hash containing data of JSON-compatible model. They already do so, and they are quite well known in the field. It only makes sense to follow their lead, so your potential users can recognize capabilities of your application easier.

[msackman]

Excellent points well made :) I think I may well change the description then as you suggest, and once I have clients that support the same API model as things like ZODB then I'd describe it as something like "document store that can also be accessed like an object store" (well, hopefully not that long winded...).