IDE: To Be Determined
IntraWeb 14 and 16 support all the way back to Delphi/C++ 2009. For IntraWeb 14 that means twelve Delphi/C++ compilers, and for IntraWeb 16, thirteen compilers. This really complicates the build process and complicates support issues as some are compiler specific.
Upcoming releases of IntraWeb 14 and 16 will contain voluntary telemetry which will report via an 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. For the new page type browser support will be stricter and is what is listed below:
- Chrome: 43 or possibly higher.
- Firefox: 45 or possibly higher.
- Internet Explorer: 11
- Edge: 13, but more likely 15 becuase Edge is still quite in flux itself.
- Safari: 10
- Mobile: To be determined, but advanced features may require Mobile Chrome, Mobile Firefox or other.
- Others: To be determined, if any
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.
Page17 / IWML (IntraWeb Markup Language)
Page17 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:
- Application Management
- 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.
- User management
- Ability to send admin messages
- Viewing of users and session times
- Ability to forceful close individual or all user sessions
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.
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.
Ability to post to Facebook, use Facebook login, etc.