SVG 2D Graphics Research
Application Architecture

Architecture for 2D

This is the 64-dollar architecture question for all software applications. It is why we got started on SVG 2D graphics application architecture research. To find out how best create Apps in the world of SVG.

Tony Hoare* rightly said "Inside every large program, there is a small program trying to get out." He might equally well have said "...several small programs trying to get out."

A) They are more complex. B) They have more bugs. C) They cost more in maintenance. D) Etc.

Because (like 'Topsy'**) most big Apps just grow, they are not well designed. Rather than having a sound application architecture, the App has lots of afterthoughts. And eventually it has to be rebuilt, because its design just can't cope and it becomes unreliable.

The short answer is: the programmer always wants to expand the App s/he is working on, rather than start a new one. It's the easy way out.

Each time some new functionality is needed, the easy way out is just to expand the current App, rather than rethink the overall design and come up with a good application architecture. It's about ownership: "me and my program". My program is A Good Thing, something I'm proud of, when it works right — heck, we all know how good it feels when we can say "it really seems to work!". So naturally it 'feels nicer' to make that Good Thing even more capable, even better.

Not at all. Look at PHP and Perl, for example. Your PHP App executes App B through the Exec function.

1. App A executes App B: Exec("AppB"); Plus, the tempnam( ) function generates unused file names, too, so App A can generate the name and tell App B where to put the data.
2. App A waits for App B to complete. And App A uses the readfile( ); function to read a whole file (blazingly fast).
3. App A completes what it set out to do.

That's a classic way to handle SVG. It's a classic way to get a better application architecture. See our demos, and these pages, for more detail.

When new functionality is only about Data Processing (DP), it can feel fine to expand an existing DP App. After all, any new App would only be built in the same language anyway, so you feel rather "what's the difference?".

Well, there is a whole lot of difference. Graphics Apps are different. When the new App is not just more DP, you need a fresh view. DP languages are not suited to graphics, for one thing: vis-a-vis graphics, they have awkward syntax, virtually no compile-time checking, and very poor run-time diagnostics.

Graphics Apps need a relevant language, and when there is one, such as PenDraw, it frees you to write graphic Apps in a language with elegant syntax, tight compile-time checking and focused run-time reporting. Oh, and by the way because of that compile-time checking, you have very few run-time bugs anyway.

The point is "Use each language for what it does well."

Producing SVG graphics from non-graphical data-processing languages, is unnecessarily a) hard to program, b) very buggy, c) very high maintenance.

Linking a DP language App to a GP language App is straightforward and much more productive.

That's what we mean by Good Architecture. That's why we undertake this SVG 2D Graphics Application Architecture Research.

* Tony Hoare? A great Computer Scientist.

** In Mrs Beecher Stowe's "Uncle Tom's Cabin" Topsy, a little girl, asserted she had neither father nor mother. When asked who made her, she replied "I 'spect I just growed." It's an over-used quote, but even a computing guy can pretend to literacy.