[CWB] CQPweb: help wanted for client objects

Ian Worthington worthy.vii at gmail.com
Thu Jul 11 10:08:52 CEST 2019


Hey Andrew, I understand what you're trying to do a bit better now.
I said it already, but I think you should simply wrap the Php API up to
expose Open API endpoints and just have the clients write themselves (look
at the way the modern web is with things like Google, Sendgrid, Stripe etc,
all of those API's are using generated clients) based on a nice metadata
doc of the Api.

http://zircote.com/swagger-php/

I think this allows you to annotate the PHP endpoints, and then create a
new endpoint which hosts a computer-readable metadata doc of the API which
can be used to literally just generate clients in any code.

There might be other reasons you don't want to do this but just wanted to
share that link with you (I'm not a PHPer)

On Thu, 11 Jul 2019 at 16:57, Hardie, Andrew <a.hardie at lancaster.ac.uk>
wrote:

> Hi José,
>
>
>
> The clients have their own tree in the repo, here:
>
>
>
> https://sourceforge.net/p/cwb/code/HEAD/tree/gui/cqpweb-client/trunk/
>
>
>
> >> Is the idea to have a client written in Python to interact with a REST
> API written in PHP?
>
>
>
> Yes, except I am not sure the API will abide by the rules of REST.
>
>
>
> To clarify: the API is accessed via an entry point within the normal
> CQPweb tree, at http://your.server.net/cqpweb/*CORPUS*/api.php
> <http://your.server.net/cqpweb/CORPUS/api.php> . Functions can be called,
> and arguments sent, using GET/POST parameters on that entry point script.
>
>
>
> The client objects are designed to be embedded into a larger software unit
> in the language of the user’s choice to make accessing the API less
> inconvenient.
>
>
>
> That will allow other GUIs to be written that use CQPweb as a backend
> while handling user interaction in whatever way they like.
>
>
>
> That’s the idea anyway; the API is not yet complete. The available
> functions so far can be seen at
>
>
> https://sourceforge.net/p/cwb/code/HEAD/tree/gui/cqpweb/trunk/lib/api-lib.php
>
> lines 50 thru 73.
>
>
>
> best
>
>
>
> Andrew.
>
>
>
>
>
> *From:* cwb-bounces at sslmit.unibo.it <cwb-bounces at sslmit.unibo.it> *On
> Behalf Of *José Manuel Martínez Martínez
> *Sent:* 07 July 2019 18:16
> *To:* cwb at sslmit.unibo.it
> *Subject:* Re: [CWB] CQPweb: help wanted for client objects
>
>
>
> Hi Andrew,
>
> this sounds interesting. But I'm not sure if I understand it. Where can I
> find the Python client? Is the idea to have a client written in Python to
> interact with a REST API written in PHP?
>
> Cheers,
>
> José Manuel Martínez Martínez
>
> https://chozelinek.github.io
>
> On 04.07.19 05:49, Hardie, Andrew 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
>
> http://liste.sslmit.unibo.it/mailman/listinfo/cwb
>
> _______________________________________________
> CWB mailing list
> 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/20190711/649974e4/attachment-0001.html>


More information about the CWB mailing list