There's nothing to stop you talking http to machines further afield. Just saying that it'd be nice to have https in the mix. Not sure what to say about that though now. It's just not tested.
After a bit of a chat here, I guess we could file feature requests / bug reports via github so that we don't pollute the list here. On 29 September 2014 16:35, Steven Taylor <[email protected]> wrote: > "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
