Talk:Multi-Process Client VAG -- draft

General

• General insights on issues related to massively decoupled 3D clients would be most welcome. If it's performance-related, please supply numbers.

• I'll get rid of the logo-size graphic under the almost-pointless and space-wasting NavBox when the NavBox is removed or replaced by an additional menu beneath the TOOLBOX section on the left. (See Template_talk:AWG_NavBox). Meanwhile that wasted space below NavBox might as well hold a logo-type graphic for the VAG. --Morgaine Dinova

Use Cases

• Because of the mix'n'match nature of clients made up from numerous decoupled components, the sky is the limit as far as use cases are concerned. If you have some really far out use case ideas, we'd love to hear about them. Even better, there's a (currently empty) Use Cases section in the draft document. you know what to do. :-) --Morgaine Dinova 03:28, 8 November 2007 (PST)

• I followed my own advice, and added some simple use cases. :-) --Morgaine Dinova 01:34, 11 November 2007 (PST)

Facility-Mediator Communications

Facility Attachment Protocol

• The first attempt at this said:

1. Facility and Mediator processes are normal <<cut>>
2. The Mediator listens permanently on a predefined Facility Request Port (a TCP port) for Facility attachment requests.
3. A Facility process requests attachment by opening a TCP connection to the Mediator on the predefined Facility Request Port and writing a standard set of details on the connection.
4. The Mediator responds to the attachment request (if it is granted) by returning a Facility Attachment Port number and closing the request connection.
5. The Mediator listens for a period on the granted Facility Attachment Port (a TCP port), awaiting an attachment from the corresponding Facility.
6. The Facility process that was granted attachment connects to the specified Facility Attachment Port.
7. The Mediator adds the new Facility to its routing table and creates an empty dispatch table for its services.

A bit of afterthought showed that this 2-tier approach was somewhat pointless, because a similar degree of flexibility can be achieved using a 1-tier approach, saving Mediator complexity. So, I'm cutting the above, leaving it here briefly only for easy reference (I'll delete it soon). --Morgaine Dinova 06:54, 17 November 2007 (PST)

Facility Data Transfer Format

• With respect to the lines:

Use a plug-in (DLL/.so) approach so that the data
structuring technology is not hardwired into the design.
[Rejected: this would balkanize Facilities badly.]

One of the greatest benefits of the Multi-Process Client architecture is that any Facility can be written in any language. In general it is not too hard to interface to any single well-known open-source data structuring library from any common language, but when that library is one of a set of different libraries loaded by plug-in then the necessary abstraction and indirection creates an explosion of complexity and results in numerous problems. It's so bad that I haven't listed the problems, but hopefully we can cross off this option anyway. --Morgaine Dinova 05:12, 13 November 2007 (PST)

Members (Stakeholders)

• Welcome Goldie, glad you can join us. :-) We need to identify potential problems and pitfalls early on this one, even though we're still in draft. It's always harder to fix fundamental problems later, and this design is totally unconventional so is bound to have issues, so get the very sharp knife out. :-)) --Morgaine Dinova 01:28, 11 November 2007 (PST)

Document Graphics

Help in overcoming the wiki's inability to convert the SVG fonts in the SVG file would be much appreciated.

• I can't get the wiki to convert the SVG fonts currently, so that the graphic can be displayed inline with [ [ Image:Multi-Process_Client_Overview_0.svg]]
  Error creating thumbnail: convert-im6.q16: delegate failed `'rsvg-convert' -o '%o' '%i'' @ error/delegate.c/InvokeDelegate/1928. convert-im6.q16: unable to open file `/tmp/magick-27987lA5-99usAidu': No such file or directory @ error/constitute.c/ReadImage/600. convert-im6.q16: no images defined `PNG:/tmp/transform_06c5bf433a90.png' @ error/convert.c/ConvertImageCommand/3258.
  -- see what I mean? :P

Looks like I'll have to convert to PNG locally, which would be a pity since the diagram is then not easily editable. --Morgaine Dinova 06:38, 8 November 2007 (PST)

• I converted the SVG images locally and uploaded PNG files in full-size, half-size, and quarter-size. It's all a bit silly, considering that the first word of SVG is "Scalable" and that all modern browsers can render SVG. Conversion to bitmap graphics on the wiki shouldn't be needed. --Morgaine Dinova 00:55, 9 November 2007 (PST)