News: JavaScript API Planned up to 1.0

Hello guys,

as usually, we’ve had an Intype synchronization session yesterday (happens each week on Wednesday) and we’ve finalized the requirements and API sets for the JavaScript up to version 1.0. So to give you an idea on what’s going to be possible with JS, and to gain some feedback, here’s the list of the sets.

Support APIs

These APIs will extend standard JavaScript library with usable stuff you might need for extending the Intype functionality.

• Exec API — Provides set of functions to execute external applications, and to capture their output through stdout.
• HTTP API — Allows working with HTTP request/responses. We plan to wrap CURL library to allow this, and if it will turn out to be real, we’d like to provide other protocols supported by CURL.
• Dialog API — Allows using simple dialogs like messages, string input (prompt), progress, open/save file, open folder, etc.
• Debug API — Bunch of functions allowing you to use the output console and internal logging system
• File API — Reading and writing files.
• UI API — A huge support for creating UIs through the JS using our AFW framework.

Intype APIs

These will allow you to work with Intype’s core.

• Document/Editor API — Through DocumentController enables you to insert or remove text, search, work with lines, work with input behaviors and filters, etc.
• Snippet API — Allows you to work with our snippet engine in more advanced way that is allowed through the classical snippets we have now.
• Event API — Will allow to observe Intype internal events.
• Search API — Working with the search system, search history, search results, etc.
• Project API — Working with the project, project folders and project files.
• String/Unicode API — Advanced working with unicode strings, parsing the unicode data, etc.

Please note, that these APIs are not yet set for certain versions, but our plan is to provide as much as possible until 0.4.

Do you see something we forgot to include, or something you’d like to have there?

The plans are great. Now I’m thinking that I still have to wait for a very long time for an unstable release. :(

jbeduya: Well, we don’t do all for one release. We are currently splitting the whole roadmap to smaller chunks to deliver faster after the 0.3.5. Also some stuff is not yet possible and requires some updates here and there, so it will be done when we will be working on related parts.

Canvas API is of course interesting thing to have, but only itself will not allow you to do the thing. Drawing into the editor requires deeper knowledge of how editor renders the text, and of course deeper understanding of the text (the parser). Not mentioning the fact, that doing a parser and a renderer plugin into the editor would be big performance issue.

The way I see this is to:

• have capability to parse source code with external parser (or update the current one), so you know where the blocks are
• plug into the editor’s renderer and render the markers respectively by the data provided by the parser

So actual rendering is piece of cake compared to other stuff needed to be done. There’s actually another thing for you to know. The first implementation of the JS will allow to only define the commands; a short-living piece of JS that is completely removed after it did it’s job. Typical use-case is to for example take the selection, then do something with the text, and put some text back. Command are considered to be like a simple event handler for onKeyDown and onTabTrigger events.

The second level of extending Intype with JS will be using it as an internal service that is alive with the application and is for example reacting on application’s events (that’s what the Event API is all about). However, stuff that creates parsing threads, renders to the editor, or extend the JS itself will always need to be done through the native plug-in.

martincohen:

• UI API — A huge support for creating UIs through the JS using our AFW framework.
• String/Unicode API — Advanced working with unicode strings, parsing the unicode data, etc.

The API looks very reasonable and it’s great to know it is coming. But I have mixed feelings about the two above. You will spend another year developing them and yet another one debugging them. All that just for a handful of highly specialized scripts that would be better off written as true plugins. Being able to do advanced stuff with scripting is neat, but I think the scripting engine shouldn’t try to cover all possible use cases. How about creating a mechanism for loading DLLs and exposing their functions to the JavaScript engine instead?