[freedict] Re: [Freedict-beta] feature request rest api

From: Andreas Josef Heil <andijh92@xxxxxx>
To: freedict@xxxxxxxxxxxxx
Date: Fri, 29 Sep 2017 12:44:22 +0200

Hi,

Sry for the delay.

Am 9/23/2017 um 2:37 PM schrieb Sebastian Humenda:

Hi Andreas

Andreas J Heil schrieb am 23.09.2017, 13:58 +0200:

Sebastian Humenda <shumenda@xxxxxx> writes:

[TOFU stripped]

Why don't you mind a REST-API? This allows us to write a client without
serverside scripting.

I think this is a communication issue, I'm absolutely fine with it :). I don't
have much resources to share, though.

About the web app I think the server side code should be as small as
possible. The rest should be in the users browser. This will improve

Mh, I'd prefer a healthy mixture. I personally wouldn't offload everything to
the client, but it is your design choice only. I regard Rust code (or any other
modern statically typed language) as easier to maintain.

'the dictionary look-up server' just for dictionary lookups and the
'community server' for sending and reviewing patches similar to dict.cc.

You have my heart for this. Is there any chance you could take part in our
Hackfest in November? I think there are interesting details to sort out.
If not, would be a VOIP-session or an IRC meeting an alternative?

I can't take part in the Hackfest, but VOIP, Irc, ... is OK.

The servers run in docker containers.

Is it possible that you could implement the services in a more loosely coupled
fashion? I'm not keen on tying us to Docker (or a different) containerisation
product. It's fine if it can work that way, but it'd be great if it could run on
different hosts as well.

I fully agree.

Hunsepll for improving search queries (Goldendict also uses hunspell).

We don't need Hunspell for this. Just extract word lists from our project. That
is actually something we wanted to do at some point: export our words as spell
checker dictionaries.
I'm currently developing a "suggestions engine" based on artificial intelligence
and the results are promising. It's not quite finished yet, but maybe that might
be something we would like to integrate? It'd allow us to enter
"interchangeable" and if it's not in the dictionary, get "replaceable" as an
alternate suggestion.

OK.

Your rust libdict library for word lookups. Because we already use rust
for libdict, we can also use it for hunspell. Bindings already exist.

Ok, I'm not sure how to progress here. I haven't implemented memory mapped I/O
for libdict-rust yet, but I'm not sure what is state of the art today. We ought
to discuss this in a different thread or somewhere else :-).

client side:

On the clientside I think about the w3c standard technologies together
with jquery, bootstrap, i18next.

I'm not a web developer. I suppose it boils down to an intelligent editor-alike
thing, assisting people to query and edit word definitions? Ambitious :-).
Although I believe it is a good thing to do. We once had the FreeDict editor,
but we were tied to computers. A web client makes us more modern.

So to be more specific, which repositories do you need? A dictionary server
repository and a client code repository?

Yes, a dictionary server repo and a client repo.

Thanks
Sebastian

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Freedict-beta mailing list
Freedict-beta@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/freedict-beta

Regards, Andy

[freedict] Re: [Freedict-beta] feature request rest api

Other related posts: