Talk:Multi-Process Client VAG -- draft

From Second Life Wiki
Jump to navigation Jump to search


  • 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

Source of viewpoint

  • I notice that Gigs added 3 references to this section, Hurd, L4, and Qmail. These are useful references, in that these projects (and many others) also seek to leave behind the monolithic mindset. Gigs then went on to write: "And dozens of other failed projects." This is worthless negativity and nothing else. It is also incorrect on at least two counts, since L4 and Qmail are both extremely successful, as are many other highly-factored projects. It is true that the Hurd cannot be counted as successful, but being an operating system microkernel it cannot be compared to an application framework either, and the success of L4 is in any case a counterargument. --Morgaine Dinova 02:41, 27 November 2007 (PST)
  • Additionally, the success or failure of some specific highly-factored applications does not automatically commute to other such applications, since examples of success and failure both exist. I'm therefore disregarding and removing his negative comment, while retaining his useful references. More such references would be welcome. Analysis of why some succeeded and others failed as a result of partitioning would be useful too. --Morgaine Dinova 02:41, 27 November 2007 (PST)
  • I've removed the references to Hurd and L4 now, since there is virtually no commonality between operating system microkernels and application frameworks. At best, the pictures in both areas feature interconnected circles --- well, so does a bunch of grapes. In terms of engineering, there is very little in common here, and there is even less that is actually relevant and useful to work on the MPClient. I did add two more examples to the list of references though, namely Unix tools and the Postfix MTA. --Morgaine Dinova 03:04, 27 November 2007 (PST)
  • I've added Apache to the list of highly-factored, socket-based applications. Apache is especially interesting because it too uses a hub-and-spokes architecture, and is widely regarded as efficient and scalable. And it's certainly successful too. --Morgaine Dinova 04:01, 27 November 2007 (PST)

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)
  • The new approach is much cleaner. We don't have an initial port-request protocol. Instead, facilities either know the port for their particular service or else pick it up from some simple client config file. If someone is really desperate to go dynamic here, then we can just define a standard query port which can be used to obtain a dynamic port from the Mediator Config Facility. I doubt if it will be needed though. --Morgaine Dinova 10:03, 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-264886D1e3Byk55MW': No such file or directory @ error/constitute.c/ReadImage/600. convert-im6.q16: no images defined `PNG:/tmp/transform_ad4d3b188627.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)