[CWB] CQPweb: help wanted for client objects

[Hardie, Andrew]

Well, your email is the first I’d ever heard of OpenAPI or its generators!

Having now had a look … I’m by no means an expert, but I don’t believe the CQPweb API<https://sourceforge.net/p/cwb/code/HEAD/tree/gui/cqpweb/trunk/lib/api-lib.php> meets all the criteria for being RESTful, which – if I understand correctly – is needful to use OpenAPI. Instead, it closely mimics interaction with the in-browser UI (in many cases, each call= one click on something in the browser).

Also, just looking at the spec for OpenAPI scares me<https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md>.

best

Andrew.

From: cwb-bounces at sslmit.unibo.it <cwb-bounces at sslmit.unibo.it> On Behalf Of Ian Worthington
Sent: 04 July 2019 05:37
To: Open source development of the Corpus WorkBench <cwb at sslmit.unibo.it>
Subject: Re: [CWB] CQPweb: help wanted for client objects

Forgive me if I'm not understanding this correctly, but wouldn't it be best to simply expose the API as an OpenAPI, then all the clients can literally write themselves using generators:
https://github.com/OpenAPITools/openapi-generator


On Thu, 4 Jul 2019 at 12:49, Hardie, Andrew <a.hardie at lancaster.ac.uk<mailto:a.hardie at lancaster.ac.uk>> wrote:
Hi all,

If you happen to be subscribed to the checkin feed for the SVN repo on sourceforge you may have noticed that I have created a number of “CQPwebClient” class definitions for different programming languages.

The idea of these is to ease use of the client API – raw API involves a lot of juggling about with GET and POST parameters. The only serious API function that is “working” theoretically at the moment is access to frequency lists. (“theoretically” because I am sure there are bugs.)

I am trying to make each client follow the same object model within the constraints of each language’s structure. The “odd one out” is the JavaScript, which is designed for asynchronous programming (As in a browser), unlike the others.

The two most complete are the JavaScript and PHP, followed by the C, the Python and the Perl. The idea is that, as far as possible, the same properties and methods should be exposed by each object model – so the sequence of calls to the client (and the parameters which need to be specified) to accomplish some task X will be the same regardless of the language.

I intend to continue to work on the JS and PHP clients myself as they are my languages of choice. (Well, actually, C is my language of choice, thus why there is a client object for C, but really it is a proof of concept rather than something I have a strong expectation of people wanting to make use of).  Plus they exemplify the asynchronous/synchronous usage generally. However, for the others, having put down the rough outlines I would very much like to hand off maintenance to people who actually know what they are doing in the respective languages.

TLDR: I would be most grateful to anyone willing to volunteer to take on primary responsibility for one of the clients other than the JS and PHP versions – especially the Python, R or Perl. (BTW – the R client is just an empty file; I have no intention of actually writing it because R’s object system gives me the heebie-jeebies.)

Or if anyone would like to contribute a client object in one of the (many) languages that I’m too scared even to touch (e.g. Java, C#, Ruby, Go, Lisp, shell, Groovy, Lua, MATLAB, BASIC, INTERCAL…) then that would also be fabulous.

Anyone who is interested – just drop a note to the list. The only requirement is that you must be happy for your contributions to be released open source (with an MIT style licence).

Thanks in advance!

best

Andrew.

_______________________________________________
CWB mailing list
CWB at sslmit.unibo.it<mailto:CWB at sslmit.unibo.it>
http://liste.sslmit.unibo.it/mailman/listinfo/cwb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://liste.sslmit.unibo.it/pipermail/cwb/attachments/20190704/a9c71d7a/attachment.html>