Historical Roadmap42, Revision 6
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 fix missing TODO items for outputting memstruct blocks in translator.
- 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.
Note: If anyone can offer working and complete Euphoria-based replacements for these libraries, we'd gladly accept those in their place.
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.
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 (see jsmn branch).
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.
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, PATH, or Euphoria bin/
- ...or use WinInet on Windows if CURL is not found locally
- ...or use system-wide CURL in PATH if CURL is not found locally
- ...or fall back to our original std/socket.e based HTTP-only routines
- ...and then finally, 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
|
- diff to current revision, view current revision history, backlinks
- Last modified Sep 29, 2020 by ghaberek