[NTLK] Einstein and newton-re roadmap ideas

[Eckhart Köppen]

Here are some ideas where to take Einstein and newton-re, would be 
interesting to get some discussion around this.

newton-re is very easy to port to new platforms, if we were to build 
e.g. 
a MessagePad 3000, this would be a good basis. It can also easily use 
host OS services such as USB to serial or networking. To me, newton-re 
looks like the ideal candidate to cover the use cases for the general 
public, e.g. use NewtonOS apps in day to day scenarios. The gaps right 
now would be enabling the platforms Einstein supports right now, and 
adding additional user interface components as needed.

Einstein is on the other hand a true emulator, and very useful for any 
development work which should end up on actual MessagePads or eMates. 
The Y2010 patch development was for example much nicer with Einstein 
than with real hardware. Einstein also preserves and documents the 
original NewtonOS architecture such as the REx concept, being able to 
investigate and demonstrate that in a working manner is an important 
part of the history of the Newton.

I would however simplify Einstein quite a bit, and exclude the cases 
newton-re can handle. Einstein covers a lot of platforms, not all of 
them with maintainers behind them, has three UI frameworks, and two 
build systems. My thinking would be to only support Linux and macOS, 
and keep either FLTK or SDL3 as the graphics layer. Windows support 
could possibly be kept, or then be handled via WSL. I would also move 
the existing support for developing Newton apps to newton-re. On the 
other hand, it would be interesting to add DAP support and improve the 
way we can control Einstein remotely so that it can be used as the 
ground truth when working with newton-re. All of that obviously 
reflected via GitHub issues.

Until newton-re is on par, a 'legacy' branch for Einstein would be 
present for urgent fixes such as security vulnerabilities, forked off 
the last official Einstein release. An alternative is to create a fork 
of Einstein for the above simplifications, but forks make more sense if 
there are two concurrent development efforts, or the original branch 
cannot be updated. Neither of that is true here though, I see this more 
as an evolution.

Some of the above is likely controversial, but I hope we can make it 
easier for people to contribute to either project, so that we can 
support new use cases quicker!

Anyways, eager to hear what people think!

Eckhart