Just a thought/suggestion for v4, why not embed an sqlite interface for JS, and use that for all the data files by default?

This would make it much easier to have other utilities interface with the same data, only needing to use an sqlite3 client library. I know it may not be as effecient as SMB, and other formats, but it would allow for much broader access with some room to grow.

Not suggesting throwing all data into a single db/file, but that db file(s) be sqlite3 based... possibly with most system/account data in one db, a per-user db, and a per-message-group db, and a single db for file areas. This could consolidate some data sources.
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

Re: SBBS Message System
By: tracker1 to Digital Man on Sat Nov 28 2015 05:37 pm

Just a thought/suggestion for v4, why not embed an sqlite interface for JS, and use that for all the data files by default?

I prefer plain text where possible/practical.

This would make it much easier to have other utilities interface with the same data, only needing to use an sqlite3 client library.

I believe plain-text makes it even *easier*.

I know it may not
be as effecient as SMB, and other formats, but it would allow for much broader access with some room to grow.

It's not all about efficiency. I have a list of things for v4 and chaning some of the data storage formats is in the cards, for sure, but I was not planning on moving to a 3rd party library for the data storage.

There are definitely debts to be paid for the use of 3rd party libraries, even if they are supposedly "free of cost". I'm not saying it won't happen, but it's not always the best choice for every project.

Not suggesting throwing all data into a single db/file, but that db file(s) be sqlite3 based... possibly with most system/account data in one db, a per-user db, and a per-message-group db, and a single db for file areas. This could consolidate some data sources.

I suppose. I certainly will take a second look at sqlite and think about it for some use cases.

digital man

Synchronet "Real Fact" #7:
Synchronet was originally intended as a replacement for WWIV BBS software. Norco, CA WX: 52.3øF, 29.0% humidity, 6 mph W wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Just a thought/suggestion for v4, why not embed an sqlite interface for
JS, and use that for all the data files by default?

I prefer plain text where possible/practical.

Agreed... I was meaning where binary formats/search is to be used.

This would make it much easier to have other utilities interface
with the same data, only needing to use an sqlite3 client library.

I believe plain-text makes it even *easier*.

Agreed... :-) I'm okay with structured plain text, where practical

I know it may not be as effecient as SMB, and other formats, but
it would allow for much broader access with some room to grow.

It's not all about efficiency. I have a list of things for v4 and
chaning some of the data storage formats is in the cards, for sure,
but I was not planning on moving to a 3rd party library for the
data storage.

I was just thinking that going to a fairly standard and well supported
database format would be a practical, and by exposing it in the JS model,
would allow for extension/access of all data even if not expressly exposed
in the api directly.

There are definitely debts to be paid for the use of 3rd party
libraries, even if they are supposedly "free of cost". I'm not
saying it won't happen, but it's not always the best choice for
every project.

Agreed, though sqlite is pretty broadly used. Even internally in Firefox
(with spidermonkey), part of websql (deprecated)... I was going to suggest implementing websql, but the API is meant to be callback/async and wouldn't
be a good fit for the synchronous execution model in Synchronet's JS.

Not suggesting throwing all data into a single db/file, but that
db file(s) be sqlite3 based... possibly with most system/account
data in one db, a per-user db, and a per-message-group db, and
a single db for file areas. This could consolidate some data
sources.

I suppose. I certainly will take a second look at sqlite and think
about it for some use cases.

Thank you.. again, mostly throwing it out there as it would allow for a lot
of extensions for what currently takes a lot of work to interface with.
It's not even my favorite embeddable db, to be honest, just feel it's the
most practical choice for embedded binary data these days.
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

Re: Re: SBBS Message System
By: tracker1 to Digital Man on Sun Nov 29 2015 11:37 am

I was just thinking that going to a fairly standard and well supported database format would be a practical, and by exposing it in the JS model, would allow for extension/access of all data even if not expressly exposed in the api directly.

Adding JS support for sqlite has been on my perpetual TODO list for a while.

If I shake a few hours loose, I may add that at sompe point.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

I was just thinking that going to a fairly standard and well supported database format would be a practical, and by exposing it in the JS

model,

would allow for extension/access of all data even if not expressly exposed in the api directly.

Adding JS support for sqlite has been on my perpetual TODO list for a

while.

If I shake a few hours loose, I may add that at sompe point.

Cool... TIA
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

El 28/11/15 a las 21:37, tracker1 escribió:

Just a thought/suggestion for v4, why not embed an sqlite interface for JS, and
use that for all the data files by default?

+1

---
þ Synchronet þ Dock Sud BBS TLD 24 HS - http://www.docksud.com.ar - telnet://bbs.docksud.com.ar