Re: AW: AW: AW: [sqlite] Function Language
Thankyou for the links. AppWeb has a different paradigm from what I am building but makes an interesting study. on Scully wrote: AppWeb might be suitable for what you need: http://www.appwebserver.org/ http://www.appwebserver.org/products/appWeb/doc/api/gen/appweb/esp_8js.html http://www.appwebserver.org/products/appWeb/doc/api/gen/appweb/c-api.html It's small-footprint, extensible through modules or compile-time (C or C++ API), server-side JavaScript and is easy to integrate SQLite's C API, using one line of integration code, per http://www.appwebserver.org/forum/viewtopic.php?t=880=sqlite3 (Have no affiliation with AppWeb, etc. Just started using it, lately.) HTH On 4/6/07, John Stanton <[EMAIL PROTECTED]> wrote: Sure. Michael Ruck wrote: > If you come up with something, please share it. > > Mike > > -Ursprüngliche Nachricht- > Von: John Stanton [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 6. April 2007 20:49 > An: sqlite-users@sqlite.org > Betreff: Re: AW: AW: [sqlite] Function Language > > By using making the connection from browser to server an RPC model I have > mapped the interface to the database instead of trying to map the database > to the Javascript objects. That also minimizes the network traffic. My > application server design has a criterion that network traffic should be > minimized. It is a great way to increase effective bandwidth. > > The generated HTML/Javascript pages have no redundancy and are compressed if > they are above a threshold size. The RPC between the browser and the server > uses sparse messages and not a great deal of redundancy. It also minimizes > the extent of execution of the slow, interpreted Javascript by partitioning > as much basic housekeeping to the more efficient server side processing. > > The server holds each database open as exclusive and shares it between users > and multiple user connections, minimizing database open and close actions, > keeping local cacheing and avoiding file locking. > > Currently I am dreaming up ways of implementing the Javascript function > level in Sqlite. Creating the JS VM when the DB opens and having one VM per > open DB instance seems to be a way of avoiding contentions and getting > fairly efficient execution and a reasonable route for an initial prototype. > Garbage collection should take care of stale objects. I can store user > defined functions as text items in a dedicated table defining aggregate and > scalar functions in a database. A syntax directed editor linked to JSLint > and RCS can maintain syntactically correct code with version control. > > Javascript would not be a good way to implement simple functions in Sqlite, > the current custome function interface to native code is far prefereable for > that but it is appropriate for implementing larger functions and one which > require frequent user alterations. > > Michael Ruck wrote: > >>How do you treat objects containing other objects? JS has the >>capabilities to build powerful object models with hashes etc. Objects, >>such as these don't map nicely to the relational model. >> >>I'm going a different way - I'm using static HTML, which requests JSON >>from the server and uses this to update the UI on the client side. >>However mapping JSON to SQL is still somewhat of an issue. I've >>tackled it by including metadata in JSON, but that's not very clean >>and I'm not really happy with it (yet.) >> >>Mike >> >>-Ursprüngliche Nachricht- >>Von: John Stanton [mailto:[EMAIL PROTECTED] >>Gesendet: Freitag, 6. April 2007 18:22 >>An: sqlite-users@sqlite.org >>Betreff: Re: AW: [sqlite] Function Language >> >>Thankyou for the thoughtful comments. It strikes me that a JS object >>and an Sqlite row map nicely. When I was writing the part of my >>application server which encapsulates Sqlite rows in JSON I was struck >>by how simple the interface was, particularly compared to XML which >>involves a little more attention to create well formed XML and a whole >>lot more involvement to parse and generate on the client side. Adding >>JSON as an alternative to XML was a good idea. >> >>I do not try to create dynamic HTML pages using JS and use a much >>simpler and more efficent application specific language compiled to >>byte code (somewhat analogous to Java or VDBE bytecode). At that >>level JS is merged into the page in such a way that the JS is matched >>to the browser and locale to remove redundancy. >> >>The sophistication in the otherwise simple application specific >>language is an inference engine to resolve a knowledge base of rules >>stored in the Sqlite database and an
Re: AW: AW: AW: [sqlite] Function Language
AppWeb might be suitable for what you need: http://www.appwebserver.org/ http://www.appwebserver.org/products/appWeb/doc/api/gen/appweb/esp_8js.html http://www.appwebserver.org/products/appWeb/doc/api/gen/appweb/c-api.html It's small-footprint, extensible through modules or compile-time (C or C++ API), server-side JavaScript and is easy to integrate SQLite's C API, using one line of integration code, per http://www.appwebserver.org/forum/viewtopic.php?t=880=sqlite3 (Have no affiliation with AppWeb, etc. Just started using it, lately.) HTH On 4/6/07, John Stanton <[EMAIL PROTECTED]> wrote: Sure. Michael Ruck wrote: > If you come up with something, please share it. > > Mike > > -Ursprüngliche Nachricht- > Von: John Stanton [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 6. April 2007 20:49 > An: sqlite-users@sqlite.org > Betreff: Re: AW: AW: [sqlite] Function Language > > By using making the connection from browser to server an RPC model I have > mapped the interface to the database instead of trying to map the database > to the Javascript objects. That also minimizes the network traffic. My > application server design has a criterion that network traffic should be > minimized. It is a great way to increase effective bandwidth. > > The generated HTML/Javascript pages have no redundancy and are compressed if > they are above a threshold size. The RPC between the browser and the server > uses sparse messages and not a great deal of redundancy. It also minimizes > the extent of execution of the slow, interpreted Javascript by partitioning > as much basic housekeeping to the more efficient server side processing. > > The server holds each database open as exclusive and shares it between users > and multiple user connections, minimizing database open and close actions, > keeping local cacheing and avoiding file locking. > > Currently I am dreaming up ways of implementing the Javascript function > level in Sqlite. Creating the JS VM when the DB opens and having one VM per > open DB instance seems to be a way of avoiding contentions and getting > fairly efficient execution and a reasonable route for an initial prototype. > Garbage collection should take care of stale objects. I can store user > defined functions as text items in a dedicated table defining aggregate and > scalar functions in a database. A syntax directed editor linked to JSLint > and RCS can maintain syntactically correct code with version control. > > Javascript would not be a good way to implement simple functions in Sqlite, > the current custome function interface to native code is far prefereable for > that but it is appropriate for implementing larger functions and one which > require frequent user alterations. > > Michael Ruck wrote: > >>How do you treat objects containing other objects? JS has the >>capabilities to build powerful object models with hashes etc. Objects, >>such as these don't map nicely to the relational model. >> >>I'm going a different way - I'm using static HTML, which requests JSON >>from the server and uses this to update the UI on the client side. >>However mapping JSON to SQL is still somewhat of an issue. I've >>tackled it by including metadata in JSON, but that's not very clean >>and I'm not really happy with it (yet.) >> >>Mike >> >>-Ursprüngliche Nachricht- >>Von: John Stanton [mailto:[EMAIL PROTECTED] >>Gesendet: Freitag, 6. April 2007 18:22 >>An: sqlite-users@sqlite.org >>Betreff: Re: AW: [sqlite] Function Language >> >>Thankyou for the thoughtful comments. It strikes me that a JS object >>and an Sqlite row map nicely. When I was writing the part of my >>application server which encapsulates Sqlite rows in JSON I was struck >>by how simple the interface was, particularly compared to XML which >>involves a little more attention to create well formed XML and a whole >>lot more involvement to parse and generate on the client side. Adding >>JSON as an alternative to XML was a good idea. >> >>I do not try to create dynamic HTML pages using JS and use a much >>simpler and more efficent application specific language compiled to >>byte code (somewhat analogous to Java or VDBE bytecode). At that >>level JS is merged into the page in such a way that the JS is matched >>to the browser and locale to remove redundancy. >> >>The sophistication in the otherwise simple application specific >>language is an inference engine to resolve a knowledge base of rules >>stored in the Sqlite database and an event driven capability linked to >>the activity of the database. >> >>The same capability which creates dynamic HTML/Javascript will also >&g
AW: AW: AW: [sqlite] Function Language
If you come up with something, please share it. Mike -Ursprüngliche Nachricht- Von: John Stanton [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 6. April 2007 20:49 An: sqlite-users@sqlite.org Betreff: Re: AW: AW: [sqlite] Function Language By using making the connection from browser to server an RPC model I have mapped the interface to the database instead of trying to map the database to the Javascript objects. That also minimizes the network traffic. My application server design has a criterion that network traffic should be minimized. It is a great way to increase effective bandwidth. The generated HTML/Javascript pages have no redundancy and are compressed if they are above a threshold size. The RPC between the browser and the server uses sparse messages and not a great deal of redundancy. It also minimizes the extent of execution of the slow, interpreted Javascript by partitioning as much basic housekeeping to the more efficient server side processing. The server holds each database open as exclusive and shares it between users and multiple user connections, minimizing database open and close actions, keeping local cacheing and avoiding file locking. Currently I am dreaming up ways of implementing the Javascript function level in Sqlite. Creating the JS VM when the DB opens and having one VM per open DB instance seems to be a way of avoiding contentions and getting fairly efficient execution and a reasonable route for an initial prototype. Garbage collection should take care of stale objects. I can store user defined functions as text items in a dedicated table defining aggregate and scalar functions in a database. A syntax directed editor linked to JSLint and RCS can maintain syntactically correct code with version control. Javascript would not be a good way to implement simple functions in Sqlite, the current custome function interface to native code is far prefereable for that but it is appropriate for implementing larger functions and one which require frequent user alterations. Michael Ruck wrote: > How do you treat objects containing other objects? JS has the > capabilities to build powerful object models with hashes etc. Objects, > such as these don't map nicely to the relational model. > > I'm going a different way - I'm using static HTML, which requests JSON > from the server and uses this to update the UI on the client side. > However mapping JSON to SQL is still somewhat of an issue. I've > tackled it by including metadata in JSON, but that's not very clean > and I'm not really happy with it (yet.) > > Mike > > -Ursprüngliche Nachricht- > Von: John Stanton [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 6. April 2007 18:22 > An: sqlite-users@sqlite.org > Betreff: Re: AW: [sqlite] Function Language > > Thankyou for the thoughtful comments. It strikes me that a JS object > and an Sqlite row map nicely. When I was writing the part of my > application server which encapsulates Sqlite rows in JSON I was struck > by how simple the interface was, particularly compared to XML which > involves a little more attention to create well formed XML and a whole > lot more involvement to parse and generate on the client side. Adding > JSON as an alternative to XML was a good idea. > > I do not try to create dynamic HTML pages using JS and use a much > simpler and more efficent application specific language compiled to > byte code (somewhat analogous to Java or VDBE bytecode). At that > level JS is merged into the page in such a way that the JS is matched > to the browser and locale to remove redundancy. > > The sophistication in the otherwise simple application specific > language is an inference engine to resolve a knowledge base of rules > stored in the Sqlite database and an event driven capability linked to > the activity of the database. > > The same capability which creates dynamic HTML/Javascript will also > generate PostScript to deliver PDF and no doubt other formats which > may show up in the future. > > Michael Ruck wrote: > >>I am all for it and am very interested in your project as I'm working >>on something similar. I've been using JS to create dynamic HTML pages >>in combination with SQLite using a JSON wrapper from this list. The >>only issue I see here is the treatment of JS objects - there's again >>the OO and relation mismatch involved. You may need some kind of OO >>mapper to map to SQLite tables/views. >> >>HTH, >>Mike >> >>-Ursprüngliche Nachricht- >>Von: John Stanton [mailto:[EMAIL PROTECTED] >>Gesendet: Freitag, 6. April 2007 02:43 >>An: sqlite-users@sqlite.org >>Betreff: [sqlite] Function Language >> >>I have been looking around at handy way to implement elaborate >
Re: AW: AW: [sqlite] Function Language
By using making the connection from browser to server an RPC model I have mapped the interface to the database instead of trying to map the database to the Javascript objects. That also minimizes the network traffic. My application server design has a criterion that network traffic should be minimized. It is a great way to increase effective bandwidth. The generated HTML/Javascript pages have no redundancy and are compressed if they are above a threshold size. The RPC between the browser and the server uses sparse messages and not a great deal of redundancy. It also minimizes the extent of execution of the slow, interpreted Javascript by partitioning as much basic housekeeping to the more efficient server side processing. The server holds each database open as exclusive and shares it between users and multiple user connections, minimizing database open and close actions, keeping local cacheing and avoiding file locking. Currently I am dreaming up ways of implementing the Javascript function level in Sqlite. Creating the JS VM when the DB opens and having one VM per open DB instance seems to be a way of avoiding contentions and getting fairly efficient execution and a reasonable route for an initial prototype. Garbage collection should take care of stale objects. I can store user defined functions as text items in a dedicated table defining aggregate and scalar functions in a database. A syntax directed editor linked to JSLint and RCS can maintain syntactically correct code with version control. Javascript would not be a good way to implement simple functions in Sqlite, the current custome function interface to native code is far prefereable for that but it is appropriate for implementing larger functions and one which require frequent user alterations. Michael Ruck wrote: How do you treat objects containing other objects? JS has the capabilities to build powerful object models with hashes etc. Objects, such as these don't map nicely to the relational model. I'm going a different way - I'm using static HTML, which requests JSON from the server and uses this to update the UI on the client side. However mapping JSON to SQL is still somewhat of an issue. I've tackled it by including metadata in JSON, but that's not very clean and I'm not really happy with it (yet.) Mike -Ursprüngliche Nachricht- Von: John Stanton [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 6. April 2007 18:22 An: sqlite-users@sqlite.org Betreff: Re: AW: [sqlite] Function Language Thankyou for the thoughtful comments. It strikes me that a JS object and an Sqlite row map nicely. When I was writing the part of my application server which encapsulates Sqlite rows in JSON I was struck by how simple the interface was, particularly compared to XML which involves a little more attention to create well formed XML and a whole lot more involvement to parse and generate on the client side. Adding JSON as an alternative to XML was a good idea. I do not try to create dynamic HTML pages using JS and use a much simpler and more efficent application specific language compiled to byte code (somewhat analogous to Java or VDBE bytecode). At that level JS is merged into the page in such a way that the JS is matched to the browser and locale to remove redundancy. The sophistication in the otherwise simple application specific language is an inference engine to resolve a knowledge base of rules stored in the Sqlite database and an event driven capability linked to the activity of the database. The same capability which creates dynamic HTML/Javascript will also generate PostScript to deliver PDF and no doubt other formats which may show up in the future. Michael Ruck wrote: I am all for it and am very interested in your project as I'm working on something similar. I've been using JS to create dynamic HTML pages in combination with SQLite using a JSON wrapper from this list. The only issue I see here is the treatment of JS objects - there's again the OO and relation mismatch involved. You may need some kind of OO mapper to map to SQLite tables/views. HTH, Mike -Ursprüngliche Nachricht- Von: John Stanton [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 6. April 2007 02:43 An: sqlite-users@sqlite.org Betreff: [sqlite] Function Language I have been looking around at handy way to implement elaborate functions in Sqlite. Implementing PL/SQL came to mind but recently it struck me that Javascript has data rules very similar to Sqlite and has the useful property that all executables are just data. Does anyone have views for or against Javascript as an embedded language for realizing functions? I see as a positive its data typing affinity with Sqlite and its widespread usage and a large base of active programmers. -- -- - To unsubscribe, send email to [EMAIL PROTECTED]
