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?
This question is probably more for DM,i was work few age ago on add sqlite support to the sbbs code. its not
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
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
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.
I would love to have SQLite abilities. This would make script development
a ton more easier and faster to do bigger projects.
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.
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.
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
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!)
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
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.
At any rate... I can perfectly add the SQLite3 extension myself and won't bother you guys with it.
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.
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 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.
The impression you left me is you would only want to add connectivity to a "real" SQL service that is enterprise class.
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.
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.
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.
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 :-).
all my points and apply them to their contributions (Cyan, echicken, and mcmlxxix - you all know which category you fall in to :-).
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.
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
Sysop: | Ree |
---|---|
Location: | Toronto, ON |
Users: | 2 |
Nodes: | 10 (0 / 10) |
Uptime: | 144:21:53 |
Calls: | 369 |
Files: | 2 |
Messages: | 38,456 |