assets/developer-notes/stephanie-gawroriski/2016/10/15.mkd

   1 # 2016/10/15
   2
   3 ## 15:50
   4
   5 One issue with the display server how I have it now is that there are quite a
   6 number of threads and IMC connections being created. And these are for
   7 potentially temporary connections. Although it could be a bit more performant
   8 if I had all these threads. But, all of these threads and connections is very
   9 error prone because there are tons of them. The simplest and easiest route to
  10 take would be to have a single connection for _all_ displays. Once a
  11 connection to a server is made, it can manage everything. Because otherwise it
  12 will be very complicated to juggle all of the connections properly. Also, this
  13 means there should be less locks. Basically the display server will use a one
  14 time connection that stays open all the time (even if there are no displays
  15 around) and manages it.
  16
  17 ## 16:00
  18
  19 So basically I need to simplify it greatly. In most cases only a single
  20 display will ever be used, and when a display is open it will generally always
  21 be open whenever it is used. So effectively right now it is over engineered
  22 when there can be a simpler and faster solution to this. A display server will
  23 only manage a given set of display.
  24
  25 ## 16:05
  26
  27 One for the auto-interpreter will just essentially perhaps be a set of tabs
  28 with canvases linked to sub-displays.
  29
  30 ## 17:25
  31
  32 What I can do also, is make it where the display server is not required to be
  33 in the class path. Clients will generally never need to create a display
  34 server at all. So as such, the server can be kept separated.
  35
  36 ## 17:27
  37
  38 I believe what I need to do first is perform some refactor of project layouts.
  39 Perhaps categorize them and such.
  40
  41 ## 17:28
  42
  43 Well, that is not really needed though.
  44
  45 ## 18:07
  46
  47 I am actually going to need a class that has a single thread managed that does
  48 the read commands and has a lock on the write commands. Everything would
  49 essentially be asynchronous. Of all the displays, only one will be able to
  50 send data at a time (due to the single thread and connection). However, the
  51 code will never listen for data, it will only send.
  52
  53 ## 19:42
  54
  55 I suppose for simplicity, should I have one display per connection? If so then
  56 that means in the auto interpreter I can just forward display connections to
  57 the master display sort of, although that would break barriers and such. So
  58 I suppose in this case, limit it to whatever displays are available.
  59
  60 ## 19:47
  61
  62 Thinking about it, there could be one display connection per client so to
  63 speak. This would essentially mean that to the server there would always only
  64 ever be a single client however. There would also just be a single thread.
  65 However, there will generally just be a single connection anyway. The auto
  66 interpreter will essentialy multiplex I suppose. However, each client will
  67 have a connection to a display server, despite using some of the same
  68 displays. If I want multiple applications running at the same time, they will
  69 all need displays. I definitely do not want to be limited to single
  70 applications at a time. So that means, for every client that is connected,
  71 they have their own display connection. So the `DisplayServer` is
  72 essentially dispatching work. For the swing display manager, there will just
  73 be a single display which represents each program running (in their own
  74 JFrame). So the auto-interpreter could forward it to its using display
  75 server, or host its own virtual one. The display server will have to manage
  76 which display is actually visible.