Have Characters that Depict Electronic Components been Discussed?

[Jim DeLaHunt]

On 2024-08-16 11:23, Martin Vahi via Unicode wrote:

> … the "cloud AI" era works largely on Virtual Private Servers (VPS) or 
> some
> analogues…, where the party that pays the rent for
> the computing resources logs in (or uses scripts/bots to log in) to the
> rented computing resources over SSH, which uses text based terminal user
> interface. In theory one could use some X11/VNC/RDP protocol and spend
> a considerable amount of the rented RAM on fancy windowing environment
> that will not be used most of the time.…

Or, and here is a crazy idea, one might run an HTTP server on the VPS, 
and have it serve HTML pages, and have the clients connect using 
existing web browsers, which can display the mixed graphics, text, and 
interactivity of the HTML pages.


> …The EFFICIENT solution: command line tools!…

The thing to be careful about when appealing to efficiency is the 
question of which costs you include in your measure of efficiency, and 
which costs you externalise and thus ignore. Among the costs of 
extending text constructs to include graphics are the cost of making 
fonts with more and more graphic "characters", the costs of figuring out 
how the make graphics out of the "characters", and the costs of text 
complexity for those other applications that don't need or want the 
graphic capability you are adding.


> … all modern general
> purpose programming languages support text. Many of them support Unicode
> text encoding, UTF8. From software development point of view the
> possibility to do graphics by just printing characters adds a really
> useful capability TO ALL THOSE PROGRAMMING LANGUAGES THAT SUPPORT UTF8.

All those modern languages also have support for generating HTML and 
implementing HTML-based applications.


> In "cloud AI" era many applications are command line applications.…
In a "cloud AI" era many applications are distributed systems which 
communicate via network-mediated interfaces. I would argue that the 
command line is among the less important interfaces of those 
applications. The network interfaces to talk to their distributed 
relatives are more important.
> … if some SSH-accessible administration command line utility wants to
> display a graph that includes a cycle, then a lot of inventiveness might
> be required.…

Or, the command line utility could spin up an HTTP server hosting an 
HTML page with an SVG illustration of the graph and its cycle, then 
print on stdout the URL of that page. That is a relatively low cost to 
implement, because there will probably be libraries available for the 
HTTP server, the HTML generation, and the SVG generation.


> An alternative is to come up with a new character encoding scheme that
> uses Unicode as a sub-set, a lot like the Unicode used ASCII as its
> subset.  The new character encoding will need to have then some UTF8
> analogue that uses UTF8 as its subset.  Decent mainstream terminal
> programs that are meant to be used at the "cloud AI" era must then adapt
> that new character encoding scheme…. The problem with this approach is
> that the various programming language implementations won't adopt it
> quickly, but some eventually will. An interim solution might be like
> Unicode is supported in ASCII-only C++ strings: special coding.
> Easier said than done, but I guess that it's theoretically possible.

Or, use the alternate, text plus graphics paradigms which already 
support this. The Unicode design principles say that Unicode is centred 
on exchange of universal plain text, and it leaves a lot of domains to 
"higher-level protocols". Why are you so reluctant to use the 
higher-level protocols?


-- 
.   --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant, Vancouver, B.C., Canada