[to do ] add an embed http server in goldendict
xiaoyifang opened this issue · 7 comments
like the implementation in kiwix
the benifit of this feature:
- can turn the goldendict into an online dictionary search engine. with the help such as ngnix ,can offer service to the internet users.
- can make command line implementation easier
related to the issues like goldendict/goldendict#618
goldendict/goldendict#37
The "structured results" I mean something that can be provided as JSON/XML API:
Merriam-Webster's API doc: https://dictionaryapi.com/products/json <- this one is pretty good. Cambridge's API: https://dictionary-api.cambridge.org/api/specification
provide an unified structure is difficult and will cost too much effort and time . This can be set as an new feature alone.
about the embed http server, My initial purpose is to offer the search result through website. and can simply convert html to plain text to satisfy the CLI.
a video demo?
Anyway this is great if this can be implemented , and should we switch GPL license to AGPL ,as GPL does not provide webservice protection.
With this and nginx, goldendict can be served as a common dictionary server.
and I think it can easily embed be as an external local service for other applications.
Some steps(In future maybe):
- change the goldendict's inner protocol to some common http url ,such as http://xxxxxx:/query?originurl=gdlookup:xxxxxx
- handle these http request and redirect to gd's inner process logic.
I tried civetweb and made another one:
https://github.com/SourceReviver/civetweb_qt_demo
The code includes serving a QImage generated via libcairo.
We just need to reinvent qrc:// with http://
Video:
civetweb is a fork of mangoose, but they are very different now. Mangoose only provides a mechanism to do multi threads, while civetweb manages threads on its own 😅.
WOW I'm glad I discovered this issue thread. I've been waiting for this feature on official GoldenDict repo on and off for 5+ years!
I'm happy to help. Note that regarding GoldenDict, I know more from a user's (and not a developer's) perspective,
Some steps(In future maybe):
- change the goldendict's inner protocol to some common http url ,such as http://xxxxxx:/query?originurl=gdlookup:xxxxxx
- handle these http request and redirect to gd's inner process logic.
I think this idea stems from this comment of mine. Yes, GoldenDict (for PC at least) uses this gdlookup protocol. IMO, what's important is that:
- Its response is HTML, just like HTTP, it's (almost) the same as HTTP in a browser. In fact, GoldenDict for Android requires a WebView engine (either Android Stock or Google Chrome), so GoldenDict sort or internally uses browser functionality. It may require extra CSS and JS, but more or less, it's simple.
- Just feeding input to
originurlcan be a bad idea, because it would likely be possible to inject a command likegdlookup:xyz && cat /../../etc/passwd. Maybe some sanitization can be a good idea.
I know that there is an HTTP server implementation for another dictionary format, SLOB (Sorted BLOB, which is little known), you can check its implementation here, itkach/aard2-web . It uses Java.
Anyway, I'm subscribing to this issue, because I want to see this idea get implemented =)
While I no longer have time to work on this, I think a reasonable path would be to decouple dict-related code into an independent module/library. Think about it, we can create a python binding to it, and creating a web interface would be as simple as dumping results into an HTML template.
The design of existing code does not consider anything else other than working with the Qt GUI. It is a lot of labour work.
BTW, I highly doubt anyone would want to learn the unnecessary internal indexing implementation used by Goldedict. It has been good for years and does a good job for the original/first GD developer to practice implementing the algorithm after university, but why not use something that is well studied and well known, like sqlite. The core value of GD is obviously not implementing yet another mini database 😅
Sorry for just talking and doing nothing, but I do think the above two issues have to be solved first, and the HTTP frontend would be as easy as writing a short script.