When SVG almost got network support for raw sockets
leonidasv.com
leonidasv.com
SVG had the same base layer functionality but network support would have been a big step towards making an open standard version of Flash. The iPhone was famously one of the last devices to drop support for Flash (due to both wild and regular security holes), and when they did, Flash (the predominant consumer web technology of the early-mid 2000s) finally died. It was a big deal. Had SVG gotten flash-like capability, it could have been a real game changer (although with giant security holes). Security back then was "somebody elses' problem" so while raw sockets seems wholly irresponsible by modern standards, back then it was the norm, partly because less than 10 million people worldwide really had any kind of risk exposure, plus the fact that the internet was still mostly decentralized, AOL was still considered a major force back then. Facebook and others with billions of users didn't exist yet.
Being the first to call the death on something seems to be an ongoing trend with Apple.
It was not well received at the time. Oh how things have changed.
The complainers were loud, but I think the majority of people who cared (99% of humanity didn't even notice, of course) were muttering "amen brother!"
iPhone customers were so desirable that, over time, the video streaming sites had to support Apple's video streaming format. They would have also supported Apple's video conferencing app, but I think Apple was unable to open-source the protocols for the video conferencing format, due to patent issues.
It's a little weird to call an open standard (like H264) "Apple's format".
I think it's pretty clever.
There are a lot of usability issues with firewalls and proxies that make implementing other streaming protocols very difficult, and the HLS design basically causes the implementer to adopt a pattern that is resilient to those problems.
Networks got a lot better after Covid had everyone work from home so IT had to sort the hot-path out for videoconferencing. Nowadays I think WebRTC would be fine, but in 2009 I think HLS was pretty smart.
Source: I write an HTTP streaming client library for a living.
Why do you think users care about “separate manifests and non-aligned segments” more than the video playing and not stalling and having to refresh?
Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
BTW, when I say "HLS is pretty backwards" I mean designed unergonomically and without clear requirements in mind, not a step back from what existed before. I would guess this is because the original specification was something like "whatever Major League Baseball can easily stream from their existing setup" (see the various Pantos drafts that ultimately became RFC8216)
Oh you're quite right! I was definitely mis-remembering silverlight.
> Separate manifests and non aligned segments have a real impact on the ability of the client to switch qualities in responsabilità to bandwith change, and this to avoid stalling.
I don't know if that's actually true. I sell ads, so I'm collecting delivery data on billions of devices, but only over the crappy internet that has a lot of ads on it, and at least for short videos, and the long videos after the places those short videos are, HLS stalls less than Dash and silverlight: HLS publishers make more money.
I would be interested in learning more.
> I mean designed unergonomically and without clear requirements in mind
I can easily agree with that. I misinterpreted what you meant by "backwards" as referring to the progress of the experience.
I mean it could be delivered via HTTP and was was built off of open standards for the manifest files. (HLS just breaks down mp4 files into smaller chunks and lists them in a text manifest file based on the mp3 playlist spec) *
It significantly moved the needle forward on how video was delivered and did so in a standards based way until DASH came along.
Not sure why the hate here for their “proprietary standard” it wasn't proprietary - just no one was using it and it eventually became a defacto standard because it “just works”.
* I know I’m simplifying this.
Scaling RTSP was difficult because it required two way signaling with the server and for the server to maintain client state. Using HTTP instead allowed for stateless servers in a CDN to easily scale and pushed stream negotiation onto the client. Besides simplifying the server side of streaming it made it much easier for clients switching from cellular to WiFi to maintain a stream, RTSP (and protocols like it) can't really handle clients switching addresses mid-stream.
There are dozens & dozens of really really good html/svg animation products that give Flash like capabilities. But there's vastly less interest in this stuff today. Fun/simple/quirky Flash-like stuff isn't nearly as unique or novel, now that we have much more upscale products & experiences. It was a magical time & Flash helped, but we've changed & these rose-colored glasses views on Flash never point out all the myriad of ways it was awful, choppy, poorly integrated, quirky to work with, & otherwise difficult.
If you want higher there are hundreds of web-dev targeting game dev systems which can be put to use. Many of these actually do have popularity. In spite of their being good Flash-ish animation toolkits, it doesn't feel like there's a ton of demand or clear winners. It's hard to imagine what we'd want it for today.
Anyway nowdays we have Godot and Unity which are both very nice. But there were definitely lost years where amateur gamedev was less accessable.
It's okay to say "please visit this from your computer" when someone opens something that requires a keyboard from a phone.
> Anyway nowdays we have Godot and Unity which are both very nice. But there were definitely lost years where amateur gamedev was less accessable.
The barrier to entry is considerably higher with these things. They require programming from the beginning. The coolest part about Flash was that you could get started without writing a single line of code. Then you could build up your understanding of the thing iteratively. You could build a simple quest-type game with just one line of code that you copy-pasted from somewhere, `goToAndStop(frameNumber)`. And then you go from there — variables, flow control, all that. Flash got a sizable number of people interested in programming. This ease of use is extremely important and it's still unmatched by any purported modern replacements.
Unless you have a captive audience, like forced to use enterprise users, this is not a winning strategy for any internet based product.
Also, the assumption that everyone will have devices in two form factors is, and I am being charitable here, naive.
Flash was great because it was popular and supported with the weight of a big company that loved its own child. Their love translated to great tooling.
Whereas the web is “community-owned” and community/committee-designed things rarely get super cool and fleshed out things like well-integrated for-everyone tooling. Instead, you mostly get self-serving projects that serve the creator’s own need primarily. Usually half-baked. And it’s not interoperable with anything else.
And those are?
> now that we have much more upscale products & experiences.
And those are?!!
Surely lack of hardware acceleration and poor implementation are incidental, not fundamental issues. Just as browsers eventually got their own PDF implementations because Adobe's sucked, I expect the same would have happened for Flash eventually.
> We also have ~3 major open source browser engines that independently implement the web compared with one closed source vendor.
We have WebKit and Gecko, and the latter barely exists on mobile. I'm not convinced we're a lot better off in practice.
WebKit and Blink are not the same browser engine.
Of course not. These are just some of the many many needles of crap that broke Flash.
> I expect the same would have happened for Flash eventually.
Perhaps you underestimate just how complicated "Flash" is: It's 2023 and despite everything you can do in a modern Web browser with HTML5, SVG, JavaScript, Video and so on, we still don't have a second full reimplementation of Flash. No emulator or converter that preserves all of the authors intentions, not even with a server-side-helper to cover the differences in networking policies between the web and Flash. I still think it would take serious cash/time to do this.
And for a large company to do it would risk being sued by Adobe. They promised. I think if Adobe couldn't fix the crap-needles for whatever reason, nobody else could either. Adobe made sure of that. And nobody wants to pay the Adobe tax when Flash hurts users so bad.
PDF on the other hand, is easy enough to implement on screens in a month or less, spec-in-hand. Users who use Adobe's PDF reader deserve what they get.
> We have WebKit and Gecko, and the latter barely exists on mobile. I'm not convinced we're a lot better off in practice.
I do feel a little better off. I remember a time when every flash bug was an opportunity to airdrop malware, just buy an ad and get on every desktop PC in the world for chump change. I had to browse the Web in a VM, back when VM's on workstation PC's were still painfully slow, because I needed the ability to rewind state so often. I really don't miss that.
A small number of players working (largely) openly (i.e. we have webkit and gecko's source code!) allowed features to the Web be deployed relatively quickly, and problems fixed fast and usually with the smallest-possible harm. And I think people are sufficiently suspicious of closed-source infrastructure that people (mainly purchasing VPs at big enterprises) will be able to resist any attempts to change that.
Whereas back in the flash days there was basically just x86 desktop Windows and the few other web enabled devices were niche and didn’t properly support Flash.
The Dreamcast had a browser (based on IE) but suffered from an ancient version of flash. PDAs were uncommon, also had a browser based on IE, and also suffered from a crippled version of Flash. Smartphones were a few years off and when they did arrive also had a crippled version of Flash (or no support at all).
Flash was a format for a different era. An era when Microsoft had suffocated the tech industry. The fact that we can now view basically any website on any hardware is a massive step forward.
I agree that the modern era of the web has its problems too (I’m looking at you Google, Facebook, etc) but having been a developer and early adopter of the web, I’d still take modern web technologies over Flash any day of the week.
It wasn't quite that bad. I was running FreeBSD at the time and Flash was fine there. In fact I remember for a few years it was easier to have working Flash than working "web video".
And as good as the 3rd party hacks were, they didn’t work all of the time. I remember a few sites I needed for work which required me jumping onto a Windows VM just to use.
There also wasn’t really such thing as “web video”. Flash was the closest we had. There were some other clients supported like Real Player but it was the same problem about having to install their software too.
I had to put some kind of wrapper in, and I think it was actually using the Linux version of the plugin, but it all worked pretty reliably once it was there.
> There also wasn’t really such thing as “web video”. Flash was the closest we had. There were some other clients supported like Real Player but it was the same problem about having to install their software too.
I'm talking about slightly later, when people were pushing "web video" as a replacement for Flash for e.g. YouTube. Flash was more reliable and better supported on FreeBSD for some time, is my recollection. Although honestly straight-up <embed> also worked fine and I never felt that the move away from that was really justified.
As for the early days of web video, I think half the problem was that nobody could agree on what video format to support. Some wanted patented formats while others (namely Firefox) wanted open source formats.
I’m not sure what the end outcome was of all that but it does feel a resolution has at least now been found.
JavaScript is one.
That too in turn also covers six types of JavaScript engine.
* Mozilla * Microsoft * WebKit * Adobe * Opera
https://egbert.net/blog/articles/javascript-jit-engines-time...
Is this an idiom? What does it mean?
Additionally, the SWF format itself was way ahead of SVG. It still is to some extent: https://open-flash.github.io/mirrors/swf-spec-19.pdf - look at the part that describes shapes, and compare it to SVG.
One thing that helped was ability to have shapes with fill on each side of the edge, allowing smoothly joined scenes that can be animated at real-time. All without the use of high-precision math, Flash used integers only with some fixed-point data!
You're describing javascript in that era.
The other big thing which hit Flash was mobile. Rearchitecting it to support the equivalent of the web’s responsiveness was a huge problem which got lost in the “Steve Jobs killed Flash” narrative. Battery life wasn’t the only thing which made it unpopular on mobile – that could have been improved even though some aspects of the platform made that hard – but also the fact that Flash was based around mice and fixed-size displays. Very little of the existing content worked well (often at all) on the mobile devices which did have Flash.
Flash Lite was usually used on the devices you mention as the "app" environment instead of J2ME, BREW, or whatever.
This doesn't gel well with the bring-your-own-everything nature of the web, unfortunately. Even if you look just at React there's 50 ways to build the same thing, which I'm sure makes rolling in accessibility that "just works" across all React apps without additional effort from the developer extremely difficult. It's much more practical with UI frameworks that are strongly opinionated with only a single well-supported "happy path" for most things.
Losing the high-quality authoring environment, without anyone producing something competitive, was a pretty big blow. But for the rest, I'm quite glad to see invasive browser plugins disappear.
It had some fun games but on the Mac side it was always an unstable dumpster fire. Having the iPhone browser start to push people away from making entire Flash-based websites so they could play music and crash my browser was a godsend.
https://www.fastcompany.com/1646594/adobe-launches-hearts-an...
Example: if they didn't remove the 3.5mm headphone jack, almost nobody else would have.
Apple customers historically are often the most accepting of new things, even if that means change that involves spending more money, because Apple will cover the other end of change well (& expand a little that way).
The 3.5mm jack loss is tolerated because of airpods.
I'm old enough to remember the furor caused by Apple taking the 3.5 floppy drive when every publisher used Apple hardware for QuarkExpress & everything Adobe, replaced with this new-fangled usb thing.
The crucial thing over there was that Apple didn't bring in their own USB drive thing, but instead let IOMega try to deliver it & it went poorly for Apple customers who had big data swaps between them & others (DTP shops, magazine layouts, Photoshop artwork etc).
Second, as with all of Apple products, aesthetics concerns were more important than functionality. If you've ever dealt with that original iMac, it's a tight fit. The design ratios would be off with a floppy so it had to go.
Now I wish it didn't also have a bios battery that would freaking explode at about the 10 year mark, splattering battery acid everywhere and destroying the hardware but that's part of the long tradition of Apple's occasional exploding devices.
Iomega's Zip and Jaz drives came out in the 1994 and 1995 and were pretty popular for a while until CD-R and CD-RW drives became cheap and reliable enough in the late 1990s.
Perhaps the DTP shops were complaining about the iMac dropping the SCSI port which all Macs had had up to that point for USB, obsoleting their existing external SCSI peripherals - scanners as well as various external drives.
I find this a little hard to believe. If there really are no compromises to continuing to support the 3.5mm jack, then I would expect other phone manufacturers to continue support on their flagship devices, and hammer Apple for removing it.
I think in reality, mobile devices are so small, that having a single purpose port just doesn’t make sense. The 3.5mm port is larger in volume than a USB-C port, and USB-C is quite capable of carrying analog audio. I don’t see why any manufacturer would continue paying the cost of a 3.5mm port, when it’s so trivially rolled into other existing ports on the device.
I also suspect that the current domination of wireless headphone would have occurred even if the 3.5mm jack had stayed. After all it’s trivially easy to adapt a pair of wired headphones for a USB-C port or lightning port, and yet people still choose wireless headphones.
The only real exceptions are Asus and Sony who are both targeting niche buyers with most of their phone offerings.
I could get on board with the idea iff, phone manufactures had dual USB-C jacks (ideally one at the bottom and one at the side and this could make it easier to consume landscape content like movies/games). Right now you have to choose between audio or power delivery with one port (or have a massive dongle that's half the size of the phone).
The removal of physical keyboards from phones, lack of a serviceable battery, notch, death of the floppy, removal of ports from laptops, 3.5mm jack, these all would have completely happened, exactly like they did, exactly in the way they did, without Apple?
Instead I believe we live in a dysfunctional era of "designer as absolute dictator" and it turns out copying Apple is a safer choice then wandering through the wilderness and claiming your own path.
Investors, the board, senior management, very few have that courage and the path of Apple knockoff feels less risky.
I hate the monoculture through risk aversion, especially spearheaded by a company that seems hell-bent on turning everything into a locked down consumer-grade appliance but I get why it's that.
Why low contrast hairline grey fonts on grey backgrounds was the design trend until Apple stopped and why flat design where you can't tell if something was interactive or not was extremely popular until Apple decided it wasn't.
No, the options are not limited to “being a fortune teller” and “holding a gun.”
Ironically you try to refute "Apple is prescient" and "Apple is holding the gun" with... "Apple is omnipotent, and all their decisions turn out right and are slavishly copied by others".
> I hate the monoculture through risk aversion, especially spearheaded by a company that seems hell-bent on turning everything into a locked down consumer-grade appliance but I get why it's that.
It's amazing that you call Apple risk-averse when they, to quote you, did all these things, often against considerable backlash: "The removal of physical keyboards from phones, lack of a serviceable battery, notch, death of the floppy, removal of ports from laptops, 3.5mm jack"
Don't forget that also it wasn't just "removal of physical keyboards from phones". It was launching a completely new product for a company that never made such a product in a highly competitive market with lost of entrenched players.
Risk-averse my ass.
It's the antithesis lesson of the Edsel. It made (at that time) the big 4 recalcitrant, overly conservative, and weary of change. Everything that GM acquired ended up looking like a giant amorphous indistinguishable blob.
People just want to do well and they get spooked by failures so patterns and histories create cultures of design. Nobody knows truly what the future is so they end up doing "best practice" which is a euphemism for cultural conformity.
Apple was not this under Steve. He was pattern breaking change in both Steve I and Steve II incarnations. And he had a superhero batting average. Why that is is a huge conversation outside the scope here but yeah I agree with you.
Please reread my comment. Thanks
i mean, there's clearly enough space for it, so was it really just to make way for the (very profitable) earbud trend?
As for headphones/earphones, IIRC there was a marked trend in adoption of bluetooth headphones, so Apple bet on that. Funnily enough, the competitors that derided Apple for removing the jack, and building some of their marketing campaigns around that, would remove the jack a year later.
Personally I think you could still make a small phone with a jack, but ultimately it doesn't matter much either way. Adapters work fine and bluetooth works even better.
3.5mm is a standard that just works and works everywhere. I hate the pressure to get rid of it. It seemed nothing but self serving on the part of phone manufacturers to do so and driven partly by DRM concerns and a desire to either sell accessories (airpods) or ride a minimalism trend to shave design and manufacturing costs.
absolutely everywhere, anytime!
Than what?
No analog unpredictability or crackling, clean digital all the way to the DAC matched to the speakers, no wires to tangle or damage, reliable controls.
Also interesting that at the time Jobs did not want native apps on the iPhone, only web apps.
One could totally imagine a rewritten and modernized version of flash that became the dominant web experience (perhaps replacing HTML and javascript, which in many ways are inferior).
Of course it’s possible with enough time and money, but from all accounts Adobe could not have achieved it.
That said vector graphics and extreme sound compression was just how shit got done. In those days gaming and entertainment online was all about CD deployment, extreme delta patching, low bit rate audio (Teamspeak et al) and vector graphics when possible.
I miss those days. On top of it not yet being spoiled by billion dollar businesses, the extreme constraints meant that creative minds could excel far above and beyond corporate types. And that's why the internet had the reputation it did. The ones who were making waves were individuals and small development houses that were founder-driven. It's nothing like today.
From my memory¹ the big flash days in terms of my interaction with stuff created with it, started as I was upgrading from 36k6 to 56k at home (though I had faster access at University sites) and ended around the time I bumped up from 512kbit to 2mbit downstream.
*> But even with 56k, you're getting 5kBps.
Usually less. It was rare to connect faster than 45k on most lines, 42k on some.
Of course once upgraded (first from ~56k modem to 512kbit ADSL), and before upgrading at home but using faster connections at uni/work, there were other issues: often the sites we were getting the flash content from would not deliver nearly as fast as the new line could receive²³ so a ½Mbyte+ flash app could still take a noticeable time to arrive.
----
[1] UK here, landline internet tech rollout progress varied a lot between territories
[2] again, UK: some other-end bandwidth issues (and latency issues) might have been experienced differently where you are due to differences in [inter]national peering arrangements
[3] or if they did, there was enough latency to mask a chunk of the bandwidth benefit
I saw people saying basically the same in Twitter and almost mentioned that SVG with networking was going be positioned as a Flash competitor (and sure it makes sense!), but found no reliable source on this.
Do you have any source/link/PDF from that time mentioning this goal for SVG? I would happily update the article if you could link it here. Thanks!
It was so all pervasive you didn't have to explicitly say it.
HTML5 was flash killer. The way the Javascript standard developed was a Flash killer. Everything was aiming to kill Flash and take down Adobe.
It wasn't an explicit goal of SVG 1.2 to replace Flash. You should be able to dig out the working group charter to check that. However the way these groups worked was that there were various communities ('stakeholders' if you must) who contributed thoughts and ideas. At least one of the companies implementing SVG certainly did want a Flash competitor, and so was keen on sockets.
I think they all knew it wouldn't fly, but they get excited. You see the same with Chrome and stuff like USB and Bluetooth access.
https://github.com/ruffle-rs/ruffle
They released their first "progress report" a few weeks ago:
https://ruffle.rs/blog/2023/03/12/progress-report.html
Seems like good news. :)
[1]: https://www.gnu.org/software/gnash/
So, kept an eye on some of the other attempted players, but they didn't really seem to gain enough traction/adoption to really go places.
That's why I think this Ruffle thing has legs (eg "is going places"), as it's showing the right signs of actually getting adoption and traction. :)
Isn't it the opposite? iOS never supported Flash, which helped kill it once iOS gained popularity.
HTML was basically frozen at the time, since this was when Internet Explorer had absolute domination of the browser space and Microsoft had decided not the develop it further. But innovation could still happen in Flash which Microsoft did not control, but what still popular enough that IE has to support the plug-in.
So W3C was trying to move the web forward through specs which were independent of HTML. SVG 1.2 was not just for logos, it was intended to be viable as a stand-alone application format (which required network communication). Another attempt was XHTML 2 which was not backwards compatible with HTML, but considered a fresh start.
Firefox changed that by creating competition in the browser space, which made innovation in HTML possible again.
What utterly changed was CSS and JS, though; you could say CSS was expanded to this absurd extend because HTML was bound to stay the same during W3C and then WHATWG's organizational lock on HTML.
Of course things turned out differently, and SVG became integrated in the HTML rendering engine and browser environment.
Flash always seemed to work and load fast which likely had some role in it getting mass adoption.
Designing interactive animations (even games) without any programming knowledge was really easy.
I haven't seen anything as intuitive since.
A handful of folks in yesterday's Scratch thread were saying it could be a modern version of what Flash was. I haven't used it myself. https://news.ycombinator.com/item?id=35373052
For non-interactive things I use synfig https://www.synfig.org/ after learning some of the UI quirks it is okay for pure animation work without interaction.
As one data point, YouTube was still using flash as the default player on some old browsers and embedded players in 2015 [1]; it dropped support only in 2017 [2].
[1] https://www.theverge.com/2015/1/27/7926001/youtube-drops-fla...
[2] https://old.reddit.com/r/youtube/comments/6puoc2/did_youtube...
Actual raw (PF_INET, SOCK_RAW) sockets would allow you to do all kinds of additional crazy things beyond merely establishing a TCP connection or sending a UDP datagram.
I had the pleasure of working with Sarah at Basho long ago, one of the rare people who are as talented creatively as they are technically.
I LOVED Flash - it probably is one of the first software products I actually bought at the student price in highschool. Flash 5 was just magic, I thought.
Flash died because the iPhone killed it because Adobe refused to work with Apple to make it more secure and more power-efficient. Ultimately it was Adobe's own-goal.
And Visual Basic was similarly a self-inflicted death, when Microsoft decided to make VB.NET incompatible with the previous VB6. But what was bad for Microsoft was good for the internet, as HTML+JS ultimately replaced VB6 for enterprise apps.
FoxPro I don't know about, though. Never approached Flash/VB in terms of popularity.
Flash videos and apps got easily replaced, and animations with HTML/CSS/JS, and those bite-sized Flash games basically got replaced with mobile gaming as apps.
I don't think any of those died because they were unfashionable. They died because the world/environment they were designed for changed or left them behind.
Flash was built for the world of desktop computers with a mouse, keyboard, and relatively large amounts of RAM. It was optimized for Windows/x86 but could also be made to run on other platforms and architectures. Even on Windows it was unstable and extremely insecure. On mobile its performance was atrocious and all on onMouseDown() events (the typical click event people used) just went nowhere. Flash as written also didn't tend to handle portrait aspect ratios nor window dimension change events well if at all. Adobe was also a terrible steward of the plug-in. They did not want to put the resources into making it good, they barely kept it up with security updates.
VB was similar in that it was designed for the unconnected 32-bit desktop world. Microsoft wanted to drop the VB6 runtime and just make the VB language hosted on top of the .NET runtime. It wasn't that the language was out of fashion, lots of LOB apps were written in VB in many companies, Microsoft was just uninterested in continuing development and had a new hotness they were pushing. VB.NET was an imperfect upgrade path for VB6 developers.
Although i guess you still have the problem of serving the actual svg file. There are some http headers that can help with that (csp)
At this time of history SVG also was running on a belief that the correct solution to differing performance constraints was to have profiles. The high and low power profiles were not compatible such that you could easily end up in a position where you had content that could not display correctly in both at the same time.
SVG is a wonderful standard but it seemed pretty clear that all the scripting should be done in javascript, with SVG as an web element tag or document type.
It’s pretty cool what you can do dynamically. I have been playing with dynamic css inside of the SVG, but animations are my next step.
Our logo in an upcoming release uses inlined SVG, and it’s taking a class name property to change the text color dynamically.
https://github.com/elegantframework/elegant/blob/v2.0-alpha/...
One history of this era: https://medium.com/siliconpublishing/the-fall-and-rise-of-sv...
Covers a the general gotchas on phone number parsing (by convention, countries, and telco eccentricities).
And started using it. Thanks, Hacker News.
Oh, it’s a good thing that Full (networked) SVG didn’t get formalized.
https://leonidasv.com/til-parsing-phone-numbers-is-a-nightma...
You can always fall back to MS Paint: https://ms-paint-i.de/
Modern browsers can already communicate peer to peer (via WebRTC) and DDoS other web servers (via CORS failures or good old embedding).
Is the main concern the increased attack opportunity of non-web servers?
Although recently browsers changed rules for connecting to internal ips
There’s some more details in the WebSocket RFC for why it’s a bad idea to give access to tcp/udp sockets to untrusted code unless the receiving server is willing to receive them.
You can already cause OPTION requests, if the concern is denial of service (although these are presumably much easier to filter out at a load balancer or similar than arbitrary unauthenticated requests).
And yes, it would have made more sense to have TCP support rather than to force HTTP onto everything.
SVG stands for "scalable vector graphics" not for "static vector graphics". Scalable files, but not static or pixel oriented files can be scaled to a higher resolution without losing fidelity. You lose fidelity, when increasing the display size of a bitmap. Think of how your company logo appears, when zooming-in on a 16x16 icon version.
Which is OK I guess.