Roadmap42

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.

Not Categorized, Please Help

Search



Quick Links

User menu

Not signed in.

Misc Menu