• JSLibs

    From The_Vipah@VERT/THEVAL to All on Tue Oct 12 22:42:16 2010
    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
  • From Digital Man@VERT to The_Vipah on Thu Oct 14 22:52:18 2010
    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 ■ telnet://vert.synchro.net
  • From Ragnarok@VERT/DOCKSUD to The_Vipah on Fri Oct 22 01:24:05 2010
    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
  • From Badopcode@VERT/DHBBS to Ragnarok on Thu Feb 23 12:13:54 2012
    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
  • From art@VERT/FATCATS to Badopcode on Fri Feb 24 14:31:34 2012
    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
  • From Deuce@VERT/SYNCNIX to Badopcode on Sat Feb 25 19:46:24 2012
    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!)
  • From Badopcode@VERT/DHBBS to Deuce on Sun Feb 26 20:16:45 2012
    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
  • From Deuce@VERT/SYNCNIX to Badopcode on Mon Feb 27 02:54:03 2012
    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!)
  • From Badopcode@VERT/DHBBS to Deuce on Wed Feb 29 04:16:03 2012
    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
  • From Badopcode@VERT/DHBBS to Badopcode on Wed Feb 29 09:44:35 2012
    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
  • From art@VERT/FATCATS to Badopcode on Thu Mar 1 05:41:33 2012
    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
  • From Digital Man@VERT to Badopcode on Thu Mar 1 05:46:12 2012
    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 ■ telnet://vert.synchro.net
  • From Deuce@VERT/SYNCNIX to Badopcode on Fri Mar 2 04:26:52 2012
    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!)
  • From Deuce@VERT/SYNCNIX to Badopcode on Fri Mar 2 04:46:50 2012
    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!)
  • From MCMLXXIX@VERT/MDJ to Deuce on Fri Mar 2 14:19:02 2012
    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)
  • From echicken to Deuce on Fri Mar 2 22:12:26 2012
    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
  • From Ragnarok@VERT/DOCKSUD to Digital Man on Sat Mar 3 01:56:18 2012
    -----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