ETA: Late 2018 with betas in summer 2018
IDE: To Be Determined
IntraWeb 14 and 16 support back to Delphi/C++ 2009. Currently that means 13 Delphi compilers. Add in C++ and it doubles to 26. This really complicates the build process and complicates support issues as some are compiler specific.
Newer releases of IntraWeb contain voluntary telemetry which will report via a HTTP call basic anonymous information about your IntraWeb installation and other relevant data. All data will be reported anonymously and will not contain any private or personally identifiable information. Examples of some data reported will be IntraWeb version, IDE Version, and an anonymous ID used to prevent duplicate entries in our logs from appearing as multiple installations. This is being implemented as part of the version update check that already exists in the IntraWeb IDE package.
Using this data will allow us to get a better handle on how many users are using each of the varying Delphi/C++ versions and decide which IDE versions that IntraWeb 17 will support.
Browser: In Flux
IntraWeb 17 is taking a huge jump forward and needs to rely on the latest features available in modern browsers. Final browser support is to be determined and will also depend on the time frame of final release and how each browser performs against the advanced features needed.
IntraWeb 17 will have dual mode pages (see below for more info). For the old type forms/pages that exist currently in IntraWeb 16 and prior, the browser requirements will be more flexible.
Page 16 mode likely will support older browser including Internet Explorer, however IWML likely will only be supported by:
- Chrome: 43 or possibly higher.
- Firefox: 45 or possibly higher.
- Internet Explorer: Not supported – IE is a dead product and being replaced by Edge.
- Edge: 13, but more likely 15 because Edge is still quite in flux itself.
- Mac Browsers: To be determined
- Mobile: To be determined, but may require Mobile Chrome, Mobile Firefox or other.
Quite simply to put IntraWeb way out in the front of web development again and provide web productivity and features unavailable in any other framework in any development language or platform.
IntraWeb has features such as umPartial and other features many years before AJAX and other features appeared in the mainstream. IntraWeb 17 will be even farther ahead in comparison.
IntraWeb 17 is going to require significant changes, however we understand the importance of allowing existing code to work with minimal changes. In core areas breaking changes will be evaluated for their time required to port existing projects.
IntraWeb 17 contains a new page type (referred to as Page17 for now). Old page types (Page16) will still be supported allowing existing form to be used as is.
IntraWeb 16 and IntraWeb 17 are being developed in parallel.
IntraWeb 17 currently contains a lot of new features. As development progresses some features may be released in stages (i.e. 17.1, 17.2, etc) or pushed to future IntraWeb versions such as IntraWeb 18.
IWML (IntraWeb Markup Language)
IWML is the core feature for IntraWeb 17 and will bring features generally previously unavailable to web applications. Learn More
Server Manager is a new optional component that will work with all deployment modes (ISAPI, Apache, etc) that will allow:
- Dynamic loading and unloading of apps
- Collecting and viewing of statistics about users and apps such as session list, memory used, etc.
- Live updates – Let old users stay in an old instance while new users run on updated version of application. When all users in old instance are logged out, the old instance is disabled.
- Ability to disable applications and provide users with a message.
- Ability to send admin messages
- Viewing of users and session times
- Ability to forceful close individual or all user sessions
Atozed Compact Object Readable Notation
IWML is uses ACORN. ACORN is an expandable specification to designed to allow flexibility, compactness, ease of reading, ease of parsing, and ease of streaming. ACORN was designed after being disappointed by the extreme chattiness and shiftiness (frequent use of shifted keystrokes) of XML, and the severe limitations as well as lesser (compared to XML) but still present chattiness and shiftiness of JSON.
ACORN is an EOL delimited specification which makes parsing significantly easier.
We intend to document and open ACORN for free use by anyone.
Currently each deployment type has a unique project type. ISAPI is one project type, SA another, and so on. Source files can be shared but this creates extra maintenance issues. As part of the changes required for Server Manager a new universal project type will exist that will then be loaded dynamically by shims for ISAPI, Apache, ASP.NET (In fact ASP.NET for IntraWeb already is a shim which loads an IntraWeb library) that can load the universal library. StandAlone will not need a shim, but will also load this universal library type.
This will add one more file that is required during deployment, but this is a minor drawback worth the benefits that it will bring.
Responsive – Mobile Phone, Tablet, Desktop
The new layouts of IWML provide for a responsive layout as part of their nature and allow pages to adjust from small phone screens up to large desktop displays with ease.
Via fibers or stalled threads.
Limited automated Delphi to TypeScript translation.
This feature is still under investigation, but likely features are:
- Ability to serve short codes to WordPress pages
- Ability to serve entire pages to WordPress
- Login and user integration
- Ability to retrieve WordPress content and display it with in an IntraWeb page
Ability to post to Facebook, use Facebook login, etc.
IWML enables much easier modification of the DOM (Web page in browser) which makes it easier to perform live updates far beyond what AJAX can do. The second part of the problem is latency which is perceived as delay or sluggishness by the end user.
AJAX and other communication methods all need to go through HTTP. HTTP uses short lived connections though so to use it as a live communications channel is not viable. AJAX submits requests and waits for responses, but if the server wants to push something it has to wait for the client to check in. Each of these requests makes a new connection which even on a fast connection can take a fraction of a second – enough for the user to notice lag in responses. Heavy load on a server can also slow down connection response times because of the simple overhead of dealing with so many connection requests which cannot be cached.
WebSockets is a protocol which allows for persistent TCP connections via HTTP. WebSockets have been around for a while but usage has been hindered by varying degrees of support in browsers, but more importantly old or misconfigured proxies at the Internet Service Provider or Corporate level, effectively disabling WebSockets for many users.
As of 2017 however the situation for WebSockets has greatly improved and looks to continue increased support. WebSockets support may be an optional feature of IWML , but when used it will allow very responsive times for messages from the browser to the server and also allow the server to communicate with the browser without needing to wait for the browser to initiate communication.
This type of low lag communication channel enables higher speed events such as keypress events that can be used to process live keyboard input from the browser directly on the server. It also enables mouse movement tracking. These are just two simple examples.
This allows IntraWeb to produce applications that act nearly like a desktop application but without the security risks, no installation, and without the lag of a remote desktop session. Bandwidth used is very minimal because unlike a remote desktop sessions, raw meta data is being sent rather than scraped in bits and pieces and send along with images as remote desktop solutions must do.