Closed alerque closed 5 years ago
The logic is that I've simply not been thinking beyond using it in Ezra Project and so far the interface is geared towards the needs I have in Ezra Project. However, there's nothing that speaks against making this more generic. My idea with the API so far was to make it as simple as possible to access Sword functionality from within a nodejs application. Feel free to have a deeper look and see how the API could be useful for your purposes. I'm open for more specific suggestions on what to improve.
You can find examples on how this is being used here: https://github.com/tobias-klein/ezra-project/blob/master/app/bible_browser/translation_wizard.js Look for function calls based on the ezraSwordInterface instance in that file.
My idea with the API so far was to make it as simple as possible to access Sword functionality from within a nodejs application.
With that goal in mind, I would advise just changing the project name to be more generic and making sure the internal namespaces are likewise generic. That will make it easier to re-use in other projects as a generic wrapper (which is a good thing to have).
Implementing actual features on an as-needed basis for ezra-project is totally fine. If other projects need something that isn't covered we can always contribute said functions. Not making it sound like this is locked down to interfacing with ezra-project will just make it more inviting.
Good suggestion! I'll take that on my todo list and keep this issue open until the respective changes are implemented.
Renamed ezra-sword-interface into node-sword-interface and updated source code correspondingly.
What is the logic in making this module ezra-project specific? As far as I am aware the only other alternative is swordjs which is not a wrapper but a full JavaScript re-implementation. It seems like a JS wrapper is something that would be useful in its own right for more than just the ezra-project (in fact I had something in mind, that's why I ask).