StoreBoss News


little red riding hood

I spent the last month working on an idea for creating a Javascript app that analyzed and saved eCommerce-generated data on an end user’s local machine.

During this period, I discovered much that fascinated me about Web-based local storage, and eventually came up with an idea that intrigued me more than my original conception of StoreBoss.

It’s a much much bigger idea.

StoreBoss will now be laser-focused on empowering end-users to manage local data persistence on their machines.

Think you have a handle on this, already?

That it’s a solved, trivial problem; there’s nothing to see here?

Okay… here’s a simple test:  press CTRL->SHIFT->I

See the “Cookies” listing under “Storage” on the left panel?

Click on that.

Now see the cookies WordPress has placed on your hard drive?

Here’s the test.

Can you tell me where is their exact location on your hard drive?

Just tell me what the pathname is.

Having some trouble with that?


So if you can’t verify the actual location of cookies on your machine, how do you know they have actually been deleted when you clear storage?

If you are the trusting type, it’s not a problem.

You can just move on with your business, knowing that everything is the way it’s supposed to be, and that your browser data is safe and secure.


This is just the tip of the iceberg as to why I am going to build StoreBoss.

Unless you are an experienced developer, if you are using a browser on your desktop or phone, you are no better off than little Red Riding Hood with the Wolf at the door.

No worries.

Help is on the way.

I’m going to build StoreBoss as fast as I can!


StoreBoss goes No SQL!

local storage
You can see the code in action here

I took a bit of a dive into IndexedDB today.  Talk about the callback shuffle, but I can see why they designed it that way.

It is going to take a lot of study and JS prototyping, but I think I have an idea how I might be able to develop an app on the desktop that does not need to use to use node or npm in order to do its job.

I’m certainly not the first person to think that IndexedDB might be useful in that regard.

With that in mind, I “registered” an SQL query into local storage.

Initially, I was thinking of Local Storage as a mini repository of useful queries that could run against SQLite.

Then I began to think… why not ditch SQLLite entirely?

Why depend on a bloated server/binding npm-node apparatus to persist simple e-commerce transactions, when IndexedDB (IDB) already provides this capability in a browser?  When I can just use JS to access my data locally in a fast and secure way….

What is the sense of implementing StoreBoss using third party (who are these Githubbers anyway, and will they still be supporting their buggy plugins tomorrow?) adapters over which I have no control whatsoever and cannot have a reasonable expectation of being able to rely on long-term?  Why not build StoreBoss around the free, and W3C controlled IDB, but with convenient wrappers to suit?

If the transactional data in Stripe can be stored in a practical way in IDB — which itself is built on the concept of a transaction —  and if what is of primary importance to a real-world store owner is the notion of a transaction (or Sale, or Order: call it what you will), then IDBCursor looks like it might play an alluring role in making this metaphor work.

But let’s be clear.

What I mean by a transaction is a retail event that took place at some point that is already in the past.  For example, the sale of a tee-shirt.  Such an event has temporal attributes, as well as other description, such as value.  This event may also be rolled back, by, say, a refund.

This is not precisely what is meant by transaction in IDB.

What IDB means by a transaction ae notions of db integrity when a record that is inserted or deleted in the database in real-time and maybe something goes wrong.

These are two very different things — particularly since StoreBoss is an analytic system, that is to say, a means of reviewing and analyzing virtual events that have taken place in external, production systems — such as WooCommerce, Stripe, or a bank’s mainframe batch processing of merchant DDAs.

Deep dives coming up, but first, a simple example of how you can store a SQL query in the browser.

Interesting how Chrome complains about this, while Opera and FF don’t — providing you allow cookies to be set.  Chrome forces you to allow third-party cookies, for reasons I cannot fathom at the moment. but will have to examine more closely down the road, as I do a forensic analysis of security in IDB.

The gallery below is a trivial proof that a query can readily be stored in a kind of query Filofax.

No so trivial is that if I can find a way to hierarchically associate “queries” by store (in an IDB sense), then I might have something.  IMS was before my time, but I’m going to see if I can learn something from old school data sublanguages.

This slideshow requires JavaScript.