Roadmap to Euphoria 4.2

To-do List

Improve the build system

• Simplify Makefile rules
• Proper multi-job support
• Avoid rebuilding too often
• Eliminate need for configure

Audit documentation

• Ensure docs build correctly
• Proofread and correct errors
• Streamline publishing to web

New features

C structures
built-in

• Merge Matt's long-standing struct branch to provide these new features.
• Need to update any additional std libraries that currently wrap structures manually.

Built-in libraries

These are third-party libraries compiled directly into the backend of Euphoria, so they're always available.

JSMN
std/json.e

• Compile jsmn directly into the backend for fast JSON parsing and provide additional native routines in the std library.
• JSMN only provides a single parsing function. We'll need to provide additional routines to read/write JSON files natively.

MINIZ
std/zip.e

• Compile miniz directly into the backend and expose all routines as wrappers in the std library.
• This provides access to GZIP, DEFLATE, and ZIP file routines.

MXML
std/xml.e

• Compile mxml directly into the backend and expose all routines as wrappers in the std library.
• This provides a complete XML parser for reading and writing files.

PCRE
std/regex.e

• Upgrade PCRE library to the latest release (version 8.43 as of 23-Feb-2019).
• This is still the "old" PCRE (not PCRE2) but it's still being supported with patches and bug fixes.
• Many improvements between our current version 8.10 and latest 8.43. See ChangeLog for details.

PICOHASH
std/hash.e

• Compile picohash directly into the backend and expose via hash() function constants.
• Use this to extend hash() and actually implement MD5, SHA256, etc.

External libraries

These are third-party libraries bundled with the Euphoria installation, but require sharing the library files (.dll, etc.) as well.

CURL
std/curl.e

• Provide a complete wrapper for libcurl and include prebuilt binaries in the bin/ directory on all platforms.
• CURL is pretty much the Swiss Army knife of Internet-related communication, and can be the basis for several other std libraries.

LIBUI
std/ui.e

• Provide a complete wrapper for libui and include prebuilt binaries in the bin/ directory on all platforms.
• This provides out-of-the-box support for simple GUI applications. Larger GUI applications should still use Win32Lib, EuGTK, or wxEuphoria.

LIBSSH2
std/libssh2.e

• Provide a complete wrapper for libssh2 and include prebuilt binaries in the bin/ directory on all platforms.
• This provides out-of-the-box support for SSH, SCP, and SFTP protocols.

SQLITE
std/sqlite.e

• Provide a complete wrapper for SQLite and include prebuilt binaries in the bin/ directory on all platforms.
• This provides out-of-the-box support for simple SQL-based applications. Larger SQL applications should still use MySQL, PostgreSQL, etc.

Standard libraries

Additions or extensions to libraries written in Euphoria.

HTTP
std/net/http.e

• Add support for HTTPS (see below).
• Add other HTTP methods such as http_put(), etc.

In order to provide HTTPS support, we need to:

• Use CURL directly if it is found in the local directory or Euphoria bin/, or
• Use WinInet on Windows if CURL is not found locally, or
• Use system CURL on *NIX if CURL is not found locally, or
• Fall back to our original std/socket.e based HTTP-only routines, and then
• Return error ERR_HTTPS_UNAVAILABLE for HTTPS requests.

UUID support
std/uuid.e

• Provide a simple library for creating and parsing UUIDs.

FAQ

Q: Why not use CURL for all HTTP functions?

A: This an effort to maintain backward-compatibility with existing applications that already use http_get() or http_post(). By ensuring that we can fall back to the original routines, we'll prevent those applications from breaking if they upgrade to Euphoria 4.2. The original routines should eventually be removed in a future release, e.g. Euphoria 5.0.

Q: Why compile some things into the backend and not others?

A: We need to maintain some balance and avoid including "everything but the kitchen sink" into the backend -- leading to a bloated and unportable executables. We should also avoid making everything an external library, which creates more strain on users to package and ship their own applications. Small libraries and high-priority libraries should be built into the backend. Large and low-priority libraries should be shipped separately.