[Feedback Requested] So, I need to rename a project...
  • 0
  • Godlike Fuzzydice

    Here’s a little backstory. I have a Node.js module that is an in-memory key value store, with async disk syncing (not unlike redis, only in process, and super simple.) I called it jbase. Well, it turns out there’s a company with a database product of the same name. They own a trademark, and recently contacted me, requesting I rename my project. I’m not looking to fight them, so I’m looking for new names.

    Last night (technically, this morning at 3am) I hit on an interesting idea. Right now JBase has two APIs, a model-based on, and a super simple, straight-forward key-value api. (Most of the development is on the model api, to be blunt.) So, I was thinking, with this rename, what if I also split the two projects up? This would have a benefit of anything I develop against what’s now jbase will have a migration path to a more grown-up database without any code changes on my part, if I do it right.

    So, without further adieu, here is my proposal:

    The project formerly known as jbase

    This would become just the simple key-value storage api. It’s simple, clean, and very targeted. There are a couple points worth talking about with this, however:

    • It has no use for promises (which currently make it slower).
      • We could make promises optional.
      • Since lodash supports chained lazy evaluation, and we use it exclusively under the hood, we could expose that, too.
    • We need to actually benchmark it so we can really talk about how fast/performant it really is. Right now we have no clue, other than, ‘good enough’.

    What’s in a name?

    I have a list of possible names we can go with:

    • trivial
    • trivialdb
    • jts
    • js-store
    • store-js
    • store.io
    • storage.io

    Right now, I favor store.io, because it’s punchy, not taken on npm, and allows for the models project to have a similiar name…

    Models.io

    This would be the current model api from jbase. We would split it off, and give it the concept of drivers. It would have a built-in memory driver (which might be so close to jbase, we don’t even bother), and should probably ship with the-project-formely-known-as-jbase as a dependency. (It’s so small, I don’t see a problem bundling the two.)

    After the split, we’ll need to implement relations, an improved type system (so we can do auto-incrementing fields), and sub documents, but those were all on my radar anyway. After which, we could probably implement a postgres driver and a redis driver, just to prove it’s possible.

    So, there’s my idea, guys. @Developers I’d really like you guys to weigh in, but other thoughts are welcome too.

    Oh, I should mention, this has some impact on Precursors, since we wanted to move from rethinkdb to something more lightweight while developing, and this plan would give us a clear migration path back to rethinkdb in the future.

  • 0
  • SA Member

    Some thoughts:

    1. I like ‘store.’ So, store-js and store.io sound good to me. I kind of like the whole ‘thing’ with *.js for JavaScript projects, but that might be just me.
    2. ‘Drivers’ is an overloaded term that I associate strongly with hardware. I think ‘backends’ is much clearer and more standard.

    I think splitting off the model system, e.g. as we discussed with Precursors, is a great idea. It’s both nice and easy to work with.

  • 0
  • Godlike Fuzzydice

    @Burstaholic The one problem with store.js is that it’s already on npm: https://www.npmjs.com/package/store.js.

    That doesn’t mean we can’t use the name, but it could increase confusion, and I dislike that idea.

  • 0
  • Moderator

    I like ‘trivial,’ or ‘trivialdb’ - ‘trivialdb’ because it specifies what the thing is. And I like ‘trivial’ in general, because it sounds more interesting and less generic than ‘store,’ with the ‘db’ still getting across what it is.

    On the other hand, ‘store’ is very punchy. However,would there be a problem with something else already called store.js? We wouldn’t want too much confusion.

    Also, would ‘jstore’ be a possibility? I like the sound of it better than ‘js-store.’

  • 0
  • Godlike Fuzzydice

    @Leftie “JStor” and “JStore” are actual journal article websites, it looks like.

    And, don’t get me wrong, I like trivial or trivialdb. I may even like trvialdb better than store.io the longer I think about it… but what ever would we call the model library?

  • 0
  • SA Member

    Going with the pun of ‘trivia’ for the models project appeals to me, but may be insufficiently descriptive.

  • 0
  • Godlike Fuzzydice

    @Burstaholic To some extent, that’s what descriptions and keywords are for; when you search for “key value json” in npm, jbase currently is at the top of the list. So, with creative keywords, we can make sure the project gets found in most searches, and then as it gets popular, it’ll naturally be ranked higher.

    On the other hand, something to consider: my target audience is me. I don’t care how popular it gets, I want something with the API that I favor, that just works. That’s why I wrote it. So I can call it whatever I want, really. I’m just a crazy sod who also wants to make this stuff discoverable by anyone who agrees with my designs. XD

    To the point: I kinda like that play. I’m just not sure if I want to tie the models lib to trivialdb that much.

  • 0
  • SA Member

    I kinda like that as a name for a models library all on its own, actually.

    “Trivia: An Easy Database ORM”

  • 0
  • Godlike Fuzzydice

    @Burstaholic Hmm… that’s not bad.

  • 1
  • Godlike Fuzzydice

    So, with some more thought in this, right now, I really tempted to go with:

    • jbase => trivialdb, “TrivialDB: A simple json-backed key value store.”
    • model api => trivia, “Trivia: An Easy Database ORM”

    last edited by WhiteLynx
  • 0
  • SA Member

    Since you do in fact have a few users, some thought will need to be put into deprecation + migration, but I like it.

  • 0
  • Godlike Fuzzydice

    @Burstaholic My plan is to use npm depricate and put a big notice on the jbase npm project. Should work well.

  • 0
  • SA Member

    I personally liked Store.IO and Models.IO quite a bit, but I really can’t argue against TrivialDB and Trivia either. Either should work well, I think.

    I also agree with @Burstaholic about using the term “backend” instead of “driver”. (I also like it better than knex’s choice of “dialect”, since it involves more than just the query language dialect used to render queries)

  • 0
  • Godlike Fuzzydice

    Now that I’ve had time to sleep on it, I think I’m going to go with trivialdb and trivia.

    I doubt I’ll get to this for a few days, so there’s still time to register dissention.

  • 0
  • Godlike Fuzzydice

    I lied. I renamed jbase to trivialdb.

    I’ll worry about splitting the project a little later.

  • 15
    Posts
  • 2159
    Views
  • Log in to reply
  • Looks like your connection to [Feedback Requested] So was lost, please wait while we try to reconnect.