"This is pretty interesting to me. Although I wonder if it runs on Linux, with mono?"
new @TODO: add mono to the build system so that additional targets are produced. In terms of compatibility with mono, I went as primitive as possible in the base class library to implement "wget". Nothing is guaranteed. However, shouldn't be too far off the mark for mono. https is not yet test either. Inadequate list of scenarios thus far are that JHS / JD server + other components will reside on the same server or on the same local network. Not too bad depending on the architecture, but not a complete set of scenarios yet. There's a fairly sensible way to add these incrementally though. On 29 September 2014 16:14, Jon Hough <[email protected]> wrote: > This is pretty interesting to me. Although I wonder if it runs on Linux, > with mono? > > > > --- Original Message --- > > From: "Steven Taylor" <[email protected]> > Sent: September 29, 2014 10:00 PM > To: "Programming forum" <[email protected]> > Subject: [Jprogramming] A .Net J Http Connector > > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
