Re: Text terminal rendering design

H. S. Lahman wrote:
Since the client is external, the interface for your software
provides encapsulation and implementation decoupling. That
encapsulation hides the implementation of your software from
the client. So proper decoupling at the subsystem level /demands/
that the client should not know what objects implement your
software, much less where they are located in memory.

But how can the client ever know what objects implement my software?
The client will inevitably have to call methods of my objects, but
thanks to encapsulation that is the limit of the clients knowledge.
The objects that the client has hold of could always easily be
relaying those messages to a completely different object structure.

(If you pass back a handle, the semantics should be such that the
client doesn't know it is an object address, even if the client is
in the same address space.)

In what sense shouldn't the client know that it is an object address?
It is always actually going to be an object address.

Even if I use a symbol ID for the client and a Symbol internally,
that symbol ID is going to be represented by an identifying object.
In fact, it will be an object address simply because almost
everything is represented by objects and objects are manipulated
through object addresses. How do I tell the client to pretend this ID
isn't an object address?

I've been looking at your article about Subsystem interfaces. You
list these 5:
1. A message with no data other than a message type.
2. A message containing data passed by value.
3. A message with data passed by reference.
4. A message containing an object (e.g., a Java applet).
5. A message with an object passed by reference.

I have a feeling that you look at my giving references to Symbols to
the client as a number 4 message. However, I look at it as a number 2
message.

Symbol is technically an object, but it acts purely as data in the
interface that is given to the client. (It only has two methods, both
doing nothing but translating the symbol to standard formats. The
concept being the Symbol class is that the objects represent encoded
symbols, which is a purely data concept.

In my current design Symbol objects for the graphics terminal contain
references to Drawer objects, which are a display strategy object and
certainly not data objects, but the Symbols still behave like data,
especially to the client.

I know you will frown upon having a reference to a display strategy
object within the object that it is to display, but in a graphics
context a symbol is encoded imperatively, as a sequence of drawing
operations, and that makes the code of the Drawer object itself part
of the encoding of the symbol.

As a practical matter one always requests a window from the OS
Window Manager exactly when one instantiates a Window object on the
GUI side.

However, that "practical matter" is actually driven by the way the
OS Window Manager's interface is designed. If one waits between
instantiating the Window and making the OS Window Manager request,
there is a risk of getting out of synch and running into rude
referential integrity problems. So even though the window handle
is semantically quite abstract on the GUI side, the GUI-side
solution is being driven to some extent by it because of the
practical constraints of synchronization. IOW, the <service> tail
is wagging the <client> dog.

The influence of the OS Window Manager over the design is not quite
clear. Surely you are not saying that the OS is forcing the GUI
solution to have a 1:1 relationship between Window objects and OS
handles, because Window objects could be designed to behave
consistently even without an OS handle, though it would make the
documentation more complex.

I can only guess that what is being forced upon the GUI side is the
existence of a Window object at all. It seems the GUI must have a
Window object to wrap around the OS Window handle. There might be a
way around that, but can you imagine a GUI design without Window
objects?

It would increase my understanding if you would suggest a simple GUI
subsystem design that would fail if required to use OS Window
handles.

I want to delegate data acquisition responsibilities because they
are really orthogonal to the terminal-based criteria that
determine what sort of [Symbol] it must instantiate.

But they are not orthogonal at all. Data acquisition depends heavily
upon what data is needed, and different sorts of Symbols will always
require different data. You cannot ever instantiate two distinct
Symbol subclasses using the same data. And different data will always
give you different Symbols, unless you perform some sort of
conversion.

As I described above, Symbol objects are data objects, and so two
symbol objects containing the same data are effectively the same
object.

You have 3 ways to get the initialization data and N different
terminal contexts for which you instantiate a Symbol.

If those terminal contexts cannot share the same encoding scheme for
Symbol objects then they will need different data to initialize the
Symbols, though it might be a simple conversion. If they can share
the same encoding scheme then they can share the same factory.

If you subclass [SymbolFactory] for all those combinations you have
3N subclasses. If you delegate data acquisition you reduce that to
N + 3 total subclasses.

Except that only works of the N factories could each use any of the 3
DataAcquisitionStrategies, but that is impossible. Unless the factory
is doing some sort of conversion, the data it is given has to already
be in the required form, and there is no way that all N factories are
producing Symbols that store the data in the same form. There is no
one universal symbol encoding, not even Unicode.

Even my two current target terminals require radically different
symbol representation. No one DataAcquisitionStrategy would be
acceptable for both a PDCurses symbol and a graphical symbol.

[That's not quite true because the attributes needed may be
different for different Symbols, which would lead to a
combinatorial number of strategies for the data acquisition. I am
assuming there are only M Symbol types with different attributes
where M < N. IOW, I am assuming the same symbol type can be eaten
by more than one terminal type.]

Despite what I said above, your assumption is correct. However, when
two terminals actually share the same symbol type (ASCII is a popular
one), then they can share the same factory as well as the same
strategy.

Actually, I think [DataAcquisitionStrategy] is tied to the type of
symbol that must be produced. Values for that symbol's attributes
are what the strategy must provide.

Let's say I need to build a Symbol of SymbolX type. I will need a
strategy to provide the SymbolX attributes from each of the three
relevant sources. If a new source of initialization data appears
on the scene, I will need a new strategy for extracting that
source for SymbolX. But the terminal still eats the same SymbolX
attributes, so it would not need to change.

In addition, it might be possible to use SymbolX for multiple
terminal types. That is, multiple subclasses of [Terminal] might
be able to eat the SymbolX format. That sort of situation could
arise for lower level conversions like ASCII/unicode that just
change values.

That is all exactly right. It is just as exactly right even if
SymbolFactory and DataAcquisitionStrategy are combined into a single
class. My current design takes advantage of the fact that two
terminals might share the same Symbol type in a perfectly natural
way.
.

Relevant Pages

  • Re: Rem Desktop conflict with Interactive Logon Message
    ... > for users" window is not sent to the RD client. ... In the Group Policy window, which is focused on the Default Domain ... Security Settings, then to Local Policies, and select Security Options. ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: IE leaks, circular references, addevent et al
    ... We all understand that assigning "_foobar" property to an element is not a good idea; yet we assign event handler properties not knowing whether client does in fact support corresponding events. ... array of such `window` objects? ... If you're interested, I noticed that some things might fail in older Safari due to missing `compatMode` there, which seems to be used in `getContainerElement`. ... You need to feature test quirks mode when `compatMode` is missing. ...
    (comp.lang.javascript)
  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... RFC 793 Section 3.4 (Establishing a connection) says in part: ... packet because it would be necessary to assume a window size. ... client has already indicated a non-empty window). ... Server sends SYN/ACK and data ...
    (comp.arch.embedded)
  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... " Several examples of connection initiation follow. ... packet because it would be necessary to assume a window size. ... client has already indicated a non-empty window). ... Server sends SYN/ACK and data ...
    (comp.arch.embedded)
  • Re: Text terminal rendering design
    ... that the client should not know what objects implement your ... a single Account object in the "business" software might map into a Window object with associated Control objects in a GUI subsystem. ... However, when two terminals actually share the same symbol type, then they can share the same factory as well as the same strategy. ... The number of Symbols that can be output from Transform3 will be limited to those suitable for direct consumption by Terminals. ...
    (comp.object)