This question is probably more for DM,

Is it possible to load something like jssqlite.dll from the JSLibs collection: http://code.google.com/p/jslibs/

in synchronet? The command is LoadModule, however that does not seem to be available in whatever implementation/version of spidermonkey that is built
into synch.

The idea would be to write door games in JS and use SQLLite as a backend for data storage.

Possible?

Thanks!

-Olivier

---
þ Synchronet þ The Valley BBS | valley.darktech.org | Bulkley Valley, Smithers BC

Re: JSLibs
By: The_Vipah to All on Tue Oct 12 2010 06:42 pm

This question is probably more for DM,

Is it possible to load something like jssqlite.dll from the JSLibs collection: http://code.google.com/p/jslibs/

in synchronet? The command is LoadModule, however that does not seem to be available in whatever implementation/version of spidermonkey that is built into synch.

The idea would be to write door games in JS and use SQLLite as a backend
for data storage.

Possible?

No, but there is a mod out there for Synchronet which integrates sqlite into Synchronet and makes it available for JS scripts. Try searching through older DOVE-Net messages for announcement message from that mod's author about it.

digital man

Snapple "Real Fact" #6:
A honey bee can fly at 15mph.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

El 12/10/10 22:42, The_Vipah escribió:

This question is probably more for DM,

Is it possible to load something like jssqlite.dll from the JSLibs collection:
http://code.google.com/p/jslibs/

in synchronet? The command is LoadModule, however that does not seem to be available in whatever implementation/version of spidermonkey that is built into synch.

The idea would be to write door games in JS and use SQLLite as a backend for data storage.

Possible?

Thanks!

-Olivier

---
þ Synchronet þ The Valley BBS | valley.darktech.org | Bulkley Valley, Smithers BC

i was work few age ago on add sqlite support to the sbbs code. its not
great thin but it work fine.
http://bbs.docksud.com.ar/~ragnarok/sync

this out-off-sync with the actual code, but its easy to port to latest cvs


--
Dock Sud BBS
(quedamos pocos y nos conocemos)
telnet://bbs.docksud.com.ar
http://bbs.docksud.com.ar

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

Is it possible to load something like jssqlite.dll from the JSLibs collection: http://code.google.com/p/jslibs/

in synchronet? The command is LoadModule, however that does not seem to b available in whatever implementation/version of spidermonkey that is built into synch.

The idea would be to write door games in JS and use SQLLite as a backend f data storage.

i was work few age ago on add sqlite support to the sbbs code. its not great thin but it work fine.
http://bbs.docksud.com.ar/~ragnarok/sync

this out-off-sync with the actual code, but its easy to port to latest cvs

I would love to have SQLite abilities. This would make script development a ton more easier and faster to do bigger projects.
I was working on a Javascript menu system that was similar to OBV/2 in how you create them. Got pretty far but the choking point is trying to manipulate stupid menu files. Just grinds everything to a halt.
But on top of that I would love to be able to write a shopping cart program and sell my software projects using Synchronet's webserver.
Synch has all the user-community site features and you could design a website that could really tailor access options, for downloads for example, would be ridiculously easy. The thing that truly is the safety break for development of JS developers on Sync is the lack of powerful SQL database tools which is the norm for almost all scripters today.
I can understand Synch core developers not wanting to embrace the idea of trying to build client extensions for every possible SQL server out there and the headache that goes along with maintaining the client extenders.
But honestly I feel SQLite3 really fits the bill for Synch and is parallel to the spirit of Synchronet.
I was looking at maintaining a source code fork and building the extender myself although I really don't have time for such a project with all my other projects. But there is less to wrap on SQLite than there is on a C socket. If I was the only one whining about SQLite I probably would write it quietly in my own little corner. But I'm going to have to throw my 2 cents in now that I see its been a topic on DOVE-Net.
Seriously this would be a major boon for the folks out there writing scripts and currently is one of the major hangups for scripting on Synch.

---
þ Synchronet þ Darkest Hour BBS - thedhbbs.com

Re: Re: JSLibs
By: Badopcode to Ragnarok on Thu Feb 23 2012 07:13:54

Hi Badopcode,

Seriously this would be a major boon for the folks out there writing scripts and currently is one of the major hangups for scripting on Synch.

Possibly.

I have written doors in C# which talk with an MS SQL Server cluster. It's not difficult, with a good API around databases, which .NET provides. ECMAScript will be trickier.

I'm interested, let me know if you feel like taking this on, I'd be happy to help where I can.

Regards,

art@fatcatsbbsdotcom

"Laddie, every woman has her own charm. You just have to know
where to look for it."
-- Scotty to Riker in ST:TNG "Relics"

---
þ Synchronet þ fatcats bbs - fatcatsbbs.com

Re: Re: JSLibs
By: Badopcode to Ragnarok on Thu Feb 23 2012 07:13 am

I would love to have SQLite abilities. This would make script development
a ton more easier and faster to do bigger projects.

I have some work on adding ODBC support to Synchronet. I think that marrying a
specific engine would be a mistake - expecially one as purposefully weak as SQLite.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

I would love to have SQLite abilities. This would make script developmen a ton more easier and faster to do bigger projects.

I have some work on adding ODBC support to Synchronet. I think that marryin a specific engine would be a mistake - expecially one as purposefully weak a SQLite.

ODBC would be very cool. But SQLite is not weak and a lot lower over head than running a SQL server on the same server that your applications are running on.
As long as there is a single server scenario SQLite is a very practical alternative.
If Synch was to adopt a ODBC model it would make the most sense if Synch's db stuff got stored via ODBC instead local binary packed files.
That would go a long ways into making Synch a enterprise class super daemon. I never got the feeling that that was the direction of Synch. But I would applaud this direction as Synch naturally does social networking which is a major demand of business websites now days.
But on the downside to ODBC is that there is a level of complication to setting up ODBC drivers. On Windows its fairly simple and can be a step-by-step with screenshots. ODBC on Linux can sometimes be hellish.
Probably the best tactic to eliminating a flood of "How do I setup ODBC?" questions in the forums would be to setup ODBC as a build directive and on the precompiled distributions only compile the packed binary configs.
My thinking was just a SQLite interface that extends the Javascript engine as an alternative to regular file IO routines. ODBC for just the Javascript engine would be a bit overkill. IMHO

---
þ Synchronet þ Darkest Hour BBS - thedhbbs.com

Re: Re: JSLibs
By: Badopcode to Deuce on Sun Feb 26 2012 03:16 pm

ODBC would be very cool. But SQLite is not weak and a lot lower over head than running a SQL server on the same server that your applications are running on.

Sorry, I'm used to "real" DF servers. SQLite is indeed weak, but that's what it's trying for, so it's fine.

If Synch was to adopt a ODBC model it would make the most sense if Synch's db stuff got stored via ODBC instead local binary packed files.

Not really. Just because something *can* do a specific thing doesn't mean it makes sense to. Currently you can run Synchronet without setting up a DB server. Were Synchronet to reply on ODBC, that would no longer be the case... and that would be almost the only benefit.

That would go a long ways into making Synch a enterprise class super
daemon. I never got the feeling that that was the direction of Synch. But I would applaud this direction as Synch naturally does social networking which is a major demand of business websites now days.

There is a *lot* of things preventing Synchronet from being an enterprise class super daemon. Mostly it's just not designed for scalability. The data storage
is just one tiny part of this issue.

But on the downside to ODBC is that there is a level of complication to setting up ODBC drivers. On Windows its fairly simple and can be a step-by-step with screenshots. ODBC on Linux can sometimes be hellish.

Which is a good reason for Synchronet not to rely on an ODBC driver.

My thinking was just a SQLite interface that extends the Javascript engine as an alternative to regular file IO routines. ODBC for just the
Javascript engine would be a bit overkill. IMHO

I think writing custom SQL bindings for the JS engine and *only* supporting SQLite would be underkill. If we were going to pick a single DB to support, I would likely choose PostgreSQL.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Wow! Not the type of response I expected. Didn't mean to piss you off. I
mean I have no problem with a debate. Or even a project leader telling me no because I say no... but being blasted with a cynical circular logic
explanation like I'm a overly excited child... not cool.
Well this definitely curbs my enthusiasm.

Re: Re: JSLibs
By: Badopcode to Deuce on Sun Feb 26 2012 03:16 pm

ODBC would be very cool. But SQLite is not weak and a lot lower over head than running a SQL server on the same server that your applications are running on.

Sorry, I'm used to "real" DF servers. SQLite is indeed weak, but that's what it's trying for, so it's fine.

If Synch was to adopt a ODBC model it would make the most sense if Synch's db stuff got stored via ODBC instead local binary packed files.

Not really. Just because something *can* do a specific thing doesn't mean it makes sense to. Currently you can run Synchronet without setting up a
DB server. Were Synchronet to reply on ODBC, that would no longer be the case... and that would be almost the only benefit.

That would go a long ways into making Synch a enterprise class super daemon. I never got the feeling that that was the direction of Synch. But I would applaud this direction as Synch naturally does social networking which is a major demand of business websites now days.

There is a *lot* of things preventing Synchronet from being an enterprise class super daemon. Mostly it's just not designed for scalability. The data storage is just one tiny part of this issue.

But on the downside to ODBC is that there is a level of complication to setting up ODBC drivers. On Windows its fairly simple and can be a step-by-step with screenshots. ODBC on Linux can sometimes be hellish.

Which is a good reason for Synchronet not to rely on an ODBC driver.

My thinking was just a SQLite interface that extends the Javascript engine as an alternative to regular file IO routines. ODBC for just the Javascript engine would be a bit overkill. IMHO

I think writing custom SQL bindings for the JS engine and *only* supporting SQLite would be underkill. If we were going to pick a single DB to
support, I would likely choose PostgreSQL.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

---
þ Synchronet þ Darkest Hour BBS - thedhbbs.com

Re-reading this and maybe you didn't mean it as a slam.
But seriously you could have just said you don't like SQLite and its not something your interested in pursuing. Maybe spared some hard feelings.
The impression you left me is you would only want to add connectivity to a "real" SQL service that is enterprise class. But won't because Synchronet isn't enterprise class and by your own definitions not a "real" server. To
me, Synchronet is a "real" light weight but powerful social network server. SQLite is no different than doing everything by hand with binary packed files except your not doing the dirty foot work of writing query code.
But the most important thing is... you just don't like it and that's fine.
It's your time on this project and I can totally appreciate the fact that you don't want to mess with stuff that you don't like with your time.
I say nothing but praises about you, DM and all the other great people putting their precious time and talents into Synchronet. You guys rock. Truly.
That's why I was so shocked.
I don't know, maybe you guys get bombarded with whines and people that won't drop crap. I am a developer as well and have been through that myself. So I know how it goes. All you need is one bad day and yet one more douchebag whining for you to do something you could care less about and its postal time.
I'm sorry and apologize if I was that douchebag that touched you off. In no way was I trying to demand and was totally with the utmost respect and humbleness. But I could see how maybe my messages could get interpreted as me trying to drive marching orders.

At any rate... I can perfectly add the SQLite3 extension myself and won't bother you guys with it. I have fully done my homework on Synch JS and
SQLite3 and know exactly how to approach the matter. The only downside is
that I am not interested in trying to maintain a forked set of build files parallel to your guys CVS head or chase bugs outside of what I run into personally. So I won't release my code into the wild as it will mean having to answer whining and crying myself. That's what I was avoiding and can't blame you for not wanting to deal with that over something your don't even like.

Again I apologize if I came off sounding like I was demanding slave labor from you guys. That is not what I was trying to convey at all.

Wow! Not the type of response I expected. Didn't mean to piss you off. I mean I have no problem with a debate. Or even a project leader telling me no because I say no... but being blasted with a cynical circular logic explanation like I'm a overly excited child... not cool.
Well this definitely curbs my enthusiasm.

Re: Re: JSLibs
By: Badopcode to Deuce on Sun Feb 26 2012 03:16 pm

ODBC would be very cool. But SQLite is not weak and a lot lower over head than running a SQL server on the same server that your applications are running on.

Sorry, I'm used to "real" DF servers. SQLite is indeed weak, but that's what it's trying for, so it's fine.

If Synch was to adopt a ODBC model it would make the most sense if Synch's db stuff got stored via ODBC instead local binary packed files.

Not really. Just because something *can* do a specific thing doesn't mean it makes sense to. Currently you can run Synchronet without
setting up a DB server. Were Synchronet to reply on ODBC, that would no longer be the case... and that would be almost the only benefit.

That would go a long ways into making Synch a enterprise class super daemon. I never got the feeling that that was the direction of
Synch. But I would applaud this direction as Synch naturally does social networking which is a major demand of business websites now days.

There is a *lot* of things preventing Synchronet from being an
enterprise class super daemon. Mostly it's just not designed for scalability. The data storage is just one tiny part of this issue.

But on the downside to ODBC is that there is a level of complication to setting up ODBC drivers. On Windows its fairly simple and can be
a step-by-step with screenshots. ODBC on Linux can sometimes be hellish.

Which is a good reason for Synchronet not to rely on an ODBC driver.

My thinking was just a SQLite interface that extends the Javascript engine as an alternative to regular file IO routines. ODBC for just the Javascript engine would be a bit overkill. IMHO

I think writing custom SQL bindings for the JS engine and *only* supporting SQLite would be underkill. If we were going to pick a single DB to support, I would likely choose PostgreSQL.

---
http://DuckDuckGo.com/ a better search engine that respects your
privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

---
þ Synchronet þ Darkest Hour BBS - thedhbbs.com

Re: Re: JSLibs
By: Badopcode to Badopcode on Wed Feb 29 2012 04:44:35

Hi Badopcode,

I'll let others speak for themselves, however I have a feeling you are taking it a little bit too harshly, matey!

At any rate... I can perfectly add the SQLite3 extension myself and won't bother you guys with it. I have fully done my homework on Synch JS and SQLite3 and know exactly how to approach the matter. The only downside is

FYI, this is what I've understood you to mean, in your initial post. I don't see anything wrong with connecting Synchronet to whatever the hell you wish, out of any strange whim or volition. :)

To each their own. Keep me posted, if you progress this, please.

Kind regards,

art@fatcatsbbsdotcom

"You've made your choices, sir! You're a traitor! Now, if the bitter taste
of that is unpalatable to you, I am truly sorry. But I will not risk my
crew because you think you can dance on the edge of the Neutral Zone."
-- Picard in ST:TNG "The Defector"

---
þ Synchronet þ fatcats bbs - fatcatsbbs.com

Re: Re: JSLibs
By: Badopcode to Badopcode on Wed Feb 29 2012 04:44 am

Re-reading this and maybe you didn't mean it as a slam.
But seriously you could have just said you don't like SQLite and its not something your interested in pursuing. Maybe spared some hard feelings.
The impression you left me is you would only want to add connectivity to a "real" SQL service that is enterprise class. But won't because Synchronet isn't enterprise class and by your own definitions not a "real" server.

I'm pretty sure what he was saying was: To embed SQLite was to pick an under-powered SQL server that might not meet everyone's needs (everyone that is
interested in using a SQL server with Synchronet that is) and to embed ODBC support instead would open it up to any compliant database server and that would be better. I understand that logic.

The second part (the response to the request to reimplement Synchronet's internal databases in a SQL db engine) was that Synchronet would then not be able to run without a SQL server of some kind and that is an unusual/unexpected
requirement of a non-Enterprise class server. I totally agree with this statement and would not support reimplementing Synchronet's databases in SQL.

Two different responses to 2 different suggestions/requests.

At any rate... I can perfectly add the SQLite3 extension myself and won't bother you guys with it.

Someone (Ragnarok?) already did it. Have you looked at his patch set?

If it's considered generally useful (to more than one Synchronet sysop), I'd definitely consider integrating into the CVS tree. So far, I think there's only
been one interested sysop (before you).

digital man

Synchronet "Real Fact" #12:
Synchronet was the first BBS software to ship with internal QWK networking. Norco, CA WX: 49.9øF, 81.0% humidity, 1 mph WNW wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Re: JSLibs
By: Badopcode to Deuce on Tue Feb 28 2012 11:16 pm

Wow! Not the type of response I expected. Didn't mean to piss you off. I mean I have no problem with a debate. Or even a project leader telling me no because I say no... but being blasted with a cynical circular logic explanation like I'm a overly excited child... not cool.

Eh? I'm not pissed off, I gave you my opinions on a subject I've looked in to.
I never once said "no" or provided any circular logic. I explained what I would do if I were doing it and some reasons why.

Well this definitely curbs my enthusiasm.

*shrug*

You seem to have thin skin. Best you find out what I'm like before you try hanging out with me. I'm always willing to give my opinion, and you're always welcome to ignore it.

I'm not sure why my opinion matters that much to you.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: JSLibs
By: Badopcode to Badopcode on Wed Feb 29 2012 04:44 am

But seriously you could have just said you don't like SQLite and its not something your interested in pursuing. Maybe spared some hard feelings.

I think that's what my first reply basically said:

I have some work on adding ODBC support to Synchronet. I think that marrying a specific engine would be a mistake - expecially one as purposefully weak as SQLite.

It was after that, when (I thought) serious discussion about DB support in JS was starting that I brought out my opinions about specific APIs, methods, and DB engines.

The impression you left me is you would only want to add connectivity to a "real" SQL service that is enterprise class.

Well, what I meant is that I would prefer to not make the decision for the script writer and that Synchronet should not use ODBC for storage of its own data.

To me, Synchronet is a "real" light weight but powerful social network server.

Sure, I was just warning you that it's not enterprise class and a handfull of people working in their spare time won't get it there. Using it as a basis for
a site which massive growth is expected will likely mean re-writing everything at some point in the future.

SQLite is no different than doing everything by hand with binary packed files except your not doing the dirty foot work of writing query code.

And we already have binary packed files that work without anyone spending a largsh number of hours working very hard to make Synchronet run exactly the same.

But my objection ws to using ODBC to store the configuration data. SQLite is less bad (though the above paragraph still applies).

But the most important thing is... you just don't like it and that's fine.

I like it just fine. I've used it in a number of projects... I just don't like
it as the only option a JS scripter would have - and I would be less likely both to use it and to pitch in making it work well.

But nobody says you need my help to get anything done.

I say nothing but praises about you, DM and all the other great people putting their precious time and talents into Synchronet. You guys rock. Truly. That's why I was so shocked.

Ask anyone, I don't pull any punches when it comes to beating you over the head
with my opinion about technical subjects. Some people deal by never asking my opinion, others deal by ignoring me - it's very few who attempt to understand all my points and apply them to their contributions (Cyan, echicken, and mcmlxxix - you all know which category you fall in to :-).

It seemed everyone knew this about me, so I'm surprised that you're shocked.

I don't know, maybe you guys get bombarded with whines and people that
won't drop crap. I am a developer as well and have been through that myself. So I know how it goes. All you need is one bad day and yet one more douchebag whining for you to do something you could care less about
and its postal time.

Nah, I'm like this all the time. I'll hide my opinions at work, but nobody is payng me to shut up about Synchronet development.

You should know that DM and I disagree on some fairly basic archetectural decisions. My opinion shouldn't be the one to follow if you want to be guaranteed to have your code imported and eventually a commit bit... mine is just the one you should follow if you agree that it's the best way to do something.

I'm sorry and apologize if I was that douchebag that touched you off. In
no way was I trying to demand and was totally with the utmost respect and humbleness. But I could see how maybe my messages could get interpreted as me trying to drive marching orders.

You're free to program anything you like. If it's cool, we'll ask for you to pollute CVS with it. If it's reasonably good quality and you're willing to maintain it, we'll likely give you a commit bit. If you break stuff, we'll take it away.

Basically, talk it over with DM before you break what already works (including non-ANSI 7-bit ASCII only telnet support) and everything will be fine.

At any rate... I can perfectly add the SQLite3 extension myself and won't bother you guys with it. I have fully done my homework on Synch JS and SQLite3 and know exactly how to approach the matter.

Excellent!

So I won't release my code into the wild as it will mean having
to answer whining and crying myself. That's what I was avoiding and can't blame you for not wanting to deal with that over something your don't even like.

Having some DB access will be preferred by some to having none at all (though mcmlxxix's JSON DB is pretty awesome). If you make it a compile-time option, nobody will object to keeping it in CVS. You should likely hang out in #Synchronet on irc.synchro.net though.

Again I apologize if I came off sounding like I was demanding slave labor from you guys. That is not what I was trying to convey at all.

No apology necessary. Just as I don't expect you to care what I think, I do not yet have any reason to care what you think. :-) A little bit of code goes
a long way.


---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: JSLibs
By: Deuce to Badopcode on Thu Mar 01 2012 23:46:50

Ask anyone, I don't pull any punches when it comes to beating you over the h with my opinion about technical subjects. Some people deal by never asking opinion, others deal by ignoring me - it's very few who attempt to understan all my points and apply them to their contributions (Cyan, echicken, and mcmlxxix - you all know which category you fall in to :-).

Yeah, we all just ignore you :)

---
þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)

Re: Re: JSLibs
By: Deuce to Badopcode on Thu Mar 01 2012 23:46:50

all my points and apply them to their contributions (Cyan, echicken, and mcmlxxix - you all know which category you fall in to :-).

Hmm, I think which category I fall into changes from day to day. I find I'm more receptive to your input when my blood sugar is normal, I've had a good night's sleep and my bowels are empty.

Having some DB access will be preferred by some to having none at all (thoug mcmlxxix's JSON DB is pretty awesome). If you make it a compile-time option nobody will object to keeping it in CVS. You should likely hang out in #Synchronet on irc.synchro.net though.

The JSON DB is very useful, great for interBBS stuff as well as for local applications. Those who are most comfortable with SQL may not be able to get down with it right away, but it's worth considering where a DB is needed. Some level of SQL support wouldn't be a bad thing for those who prefer to use it (I don't feel the need for it,) but since Synchronet is typically used as a small-scale / hobbyist platform, I imagine that the JSON DB is suitable for most purposes that people put it to.

echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230

---
þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 01/03/12 05:46, Digital Man escribió:

Two different responses to 2 different suggestions/requests.

At any rate... I can perfectly add the SQLite3 extension myself
and won't bother you guys with it.

Someone (Ragnarok?) already did it. Have you looked at his patch
set?

If it's considered generally useful (to more than one Synchronet
sysop), I'd definitely consider integrating into the CVS tree. So
far, I think there's only been one interested sysop (before you).

digital man

yes, i still here !
=)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9RXh8ACgkQrka4e4h7i+MJiQCgzh3gkSDc+55pN1Q2A+U0SSUe er8An32YHn1Fwyx5MkWqhudtf/f74eiq
=rZhW
-----END PGP SIGNATURE-----

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