Roadmap to Euphoria 4.2

To-do List

Audit documentation

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

Audit tickets

• Close any completed/obsolete tickets
• Reassign open tickets to active users
• Address and close remaining tickets

Improve the build system

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

New features

memstruct Skipping memstruct for 4.2. See std/ffi.e below.

Standard libraries

std/ctypes.e

Add routines for defining and managing C types in memory.

std/json.e

Migrate mvc/json.e from Euphoria MVC

std/log.e

Migrate mvc/logger.e from Euphoria MVC

std/struct.e

Add routines for defining and managing C structures and unions in memory.

std/template.e

Migrate mvc/template.e from Euphoria MVC

std/uuid.e

Provide a simple library for creating and parsing UUIDs.

std/net/http.e

• Add support for HTTPS using CURL (see below).
• Should we keep existing code for HTTP or just rely entirely on CURL? maybe use WinInet on Windows? (see FAQ)
• Add other methods such as http_put(), etc.

Built-in libraries

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

Note: If anyone can offer native Euphoria replacements for these, we'd gladly accept those in their place!

std/ffi.e

• Compile libffi into the backend.
• Provide same API as std/dll.e using FFI instead of legacy code.
• Mark all routines in std/dll.e as deprecate.

std/hash.e

• Compile Greg's freehash library into the backend.
• Remove hash() as a built-in and make it a machine_func() instead.

std/markdown.e

• Compile MD4C into the backend.
• This provides a simple Markdown parser for getting off Creole.

std/regex.e

• Upgrade PCRE library to the latest release (version 8.45 as of 2021-06-22).
• 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.45. See ChangeLog for details.

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.

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.

External libraries

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

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 tool of Internet-related communication, and can be the basis for several other std libraries like HTTP, FTP, etc.

std/ssh.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.

std/sqlite3.e

• Provide a complete wrapper for SQLite3 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.

FAQ

Q: Should we use CURL for all HTTP functions?

A: In an effort to maintain backward-compatibility with existing applications that already use http_get() or http_post(), maybe we should fall back to the original routines to 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.