Bill: could you send a few links on web sockets? I've worked a little with web sockets in various languages... so I should probably make this a @TODO. Http still isn't a bad fall-back.
Jon: GitHub has provision for a Travis build system that is tied to check-ins. It could be proved to at least compile on mono. Also, I've started filing requests as issues on GitHub. thanks, -Steven On 1 October 2014 10:21, bill lam <[email protected]> wrote: > JD can also work without JHS, I added a simple demo to j803 beta > in which JD is running inside a websocket server provided by Jqt. > The client used is javascript inside a web browser. > > Пн, 29 сен 2014, Steven Taylor написал(а): > > Hi, > > > > I've been fairly quiet on the list of late, but I've got a tiny project > > that might be of interest. It's called *FSharp.Control.JSoftware*. It > > connects to JHS / JD over http. It's actually my third version of this > > project. I seem to start from scratch each year or so. This version > could > > be more feature rich, but I tore out a as many elements as possible in > > order to minimise dependencies. If there's interest in this approach, > some > > of those features might slowly make their way back in. > > > > Brief feature outline: > > > > - out-of-process > > - text & JSON support > > - JBIN was working, but I tore that out to minimise dependencies. > > Putting that back in is a @TODO item > > - eval + J function support > > > > > > To document / To do: > > > > - how to extend JD with J functions > > - what that eval code should look like > > - JD server set-up + start-up (I've got some c-shell scripts that I > > know run on Windows + a short sequence of steps. Those aren't > included > > here yet. Another @TODO) > > - Get the travis build working > > > > Please note that that JD approach doesn't have to be just for databases. > > For example, I've exposed some functions via this interface that don't do > > anything with a database. I really liked the way that JHS / JD have been > > moving in, so I tried to align myself with this as much as possible. > > Command based rather than REST based might makes sense in a number of > > scenarios. > > > > Code notes: > > > > It's written in C#, but there'll most likely be extensions in F# (or > > possibly an F# rewrite) in the near future. So to avoid later > confusion, I > > went for the FSharp.Control.JSoftware namespace early on. > > > > Thoughts on cross platform: > > > > - lots more to say here, but this approach (or any actually) could be > > converted to Swift-lang, or cross-compiled via the Xamarin tool chain. > > Maybe if there's a template that we all like, the out-of-process idiom > > would proliferate. > > > > I almost forgot... here's the project link: > > https://github.com/sgtz/FSharp.Control.JSoftware > > > > best regards, > > -Steven Taylor > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
