The world was never pure. Meanwhile, one thing jhs lacks is reference documentation.
-- Raul On Wed, Apr 24, 2013 at 8:13 PM, Greg Borota <[email protected]> wrote: > You have same preferences as I have, concerning REST and JSON. Besides that > though I'd still go with a web server to handle the client interaction. > Which would take you out of the pure J world. > > > On Wed, Apr 24, 2013 at 7:08 PM, Dan Bron <[email protected]> wrote: > >> Given there's no one, universal answer to these questions, we'll have to >> approach it as other languages and platforms have: by making choices. >> >> I'd prefer REST over SOAP, though SOAP ha the advantage of addressing some >> of your questions below as part of its design. Within REST, I'd prefer >> JSON over XML as payload format, as I think it would be easier to format >> and parse in J than the alternatives, and because it can be naively >> consumed by JavaScript clients. I'd also expect the J application itself >> to have some say in this: e.g. Which functions to expose using which HTTP >> verbs, etc. >> >> With all that said, I'm hardly an expert in this field. I simply expect >> that effort put into developing a WS interface will have a higher return in >> today's environment than an equivalent investment in developing a(nother) >> implementation of WD. >> >> Make sense? >> >> -Dan >> >> Please excuse typos; composed on a handheld device. >> >> On Apr 24, 2013, at 7:52 PM, Greg Borota <[email protected]> wrote: >> >> > Web services; which kind to avoid flame wars? I don't think we'd be able >> to >> > please everybody even with web services. There are a ton of web service >> > protocols out there: http://en.wikipedia.org/wiki/Web_service >> > >> > What I like most is RESTful web services where you hit a certain URL to >> get >> > your data. But then how do you return the data? XML, JSON, HTML? Or you >> > could probably have different URLs for various types. e.g: >> > /x/do/j_sentence >> > /j/do/j_sentence >> > /h/do/j_sentence >> > >> > Then what verb you use? GET? That has a hard limit, of how long it can >> be, >> > it's pretty short somewhere about 2k. If you use POST you can post whole >> > files for processing. You could probably support both. Then the url could >> > be something else: >> > /j/post/do etc... >> > >> > >> > >> > >> > On Wed, Apr 24, 2013 at 6:14 PM, Dan Bron <[email protected]> wrote: >> > >> >> I am thinking of making J interoperability seamless and transparent. It >> >> will make it easier to embed J on the server-side if we make its >> interface >> >> familiar and standard, and in the current state of the IT world, that >> means >> >> web services. >> >> >> >> A WS interface will allow us to use modern frontend toolkits to write >> >> user-facing (browser-based) apps, e.g. in Flash, Silverlight, or more >> >> likely in days to come, HTML5. >> >> >> >> It'll also make it easier to offer headless J-based services into IT >> >> depts, with leas of the usual friction we encounter when presenting a >> new, >> >> (extremely) unfamiliar language. >> >> >> >> In short, it lets us express ourselves in the way we prefer (i.e. J >> code) >> >> while allowing the outside world to interact with us in the way they >> prefer >> >> (i.e. web services). >> >> >> >> For this to work, I shine the WS interface has to be implemented >> natively >> ---------------------------------------------------------------------- >> 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
