Nate Cull is a user on mastodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Possible Ways to Extend Browsers

We already do "extend" browsers with things like "external viewers." But there's not a very good integration with the browser. Ideally those external viewers should be rendering in-place inside the document, and be working together with the browser, be tightly integrated with the browser and other parts...

#docfs #webfs #kfc

web.archive.org/web/1999012714

1/

So, a solution is what's been touted under with name "component software". The basic idea is that, rather than buildig one single monolithic application that does everythig from day one, we should be building a framework or architecture that ican be dynamic in its ability to have functionality added or deleted on the fly.

@eliotberriot
@natecull

2/

@dredmorbius @eliotberriot

We have 'component software' already, that's what COM and .NET are.

We maybe need something more?

@natecull @dredmorbius @eliotberriot
Like, theoretically, sure. But, realistically, these things are still walled gardens in terms of the apps created with them.

@enkiv2 @natecull @dredmorbius @eliotberriot and the efforts to implement this type of interface for other kinds of software (i.e. OpenDoc, CORBA, XPCOM (sort of)) haven't been particularly successful.

@a_breakin_glass
I can't tell how much of the problem is technical and how much is political.

Like, component based applications are in a sense profoundly anti-corporate-capitalist in that nobody can reasonably expect to control the 'look and feel' of a user's actual experience or cockblock their competition on the user's machine.

The unix shell does composability between totally independently developed things well, on the other hand.

@natecull @dredmorbius @eliotberriot

@eliotberriot @dredmorbius @natecull @a_breakin_glass

(The web tried to do some of this with frames early on & there were many lawsuits.)

@enkiv2 @eliotberriot @dredmorbius @natecull the reason why unix shell composability doesn't work for GUIs and we have to rely on APIs is partially, again, the result of GUIs still obeying VERY old limits

@a_breakin_glass @enkiv2 @eliotberriot @natecull Could you expand on this thought?

What are the limits?

How did / do shell tools fail in them?

What if there were, I don't know, some lightweight application-wrapper that could be tossed around shell tools?

Or does that fail to address concerns of the GUI space?

(I've never designed GUI tools, and always found the space vaguely mystifying.)

@dredmorbius @a_breakin_glass @eliotberriot @natecull
GUI toolkits aren't really designed around composability. combining bits of one widget with bits of another means rewriting both, usually. widgets can't overlap, except special frame-type ones. each window is its own little domain. applications don't by default have the ability to embed each other's components. a non-technical end user certainly can't mash up two apps.

@enkiv2 @dredmorbius @a_breakin_glass @eliotberriot

Just for speculation, would a GUI widget be more composable if it were seen as a Unix-like pipe/filter mapping a stream of input events (with initial/accumulating state) to output events?

(Doing so would require a framework where an 'event' or a 'message' is itself an object; which I think Smalltalk can do but not many other OOP systems)

Or can GUI widgets fundamentally not be implemented as a stream/filter model at all?

@natecull @dredmorbius @a_breakin_glass @eliotberriot
I'm not sure how to conceptualize widgets as filters in a general sense but I'm not willing to claim it can't be done.

Nate Cull @natecull

@enkiv2 @dredmorbius @a_breakin_glass @eliotberriot

I guess one difference is that a GUI widget would be a filter over at least TWO I/O streams, bound together.

Eg, a file or database view:

* input 1: updates or refresh events from database
* input 2: keyboard or mouse user control events
* output 1: updates or view selections to database
* output 2: graphical redraws to canvas, or events to lower-level component widgets

And state still needs to be allocated/deallocated for caching, etc.

· Web · 1 · 1

@eliotberriot @a_breakin_glass @dredmorbius @enkiv2

This is where I'd *like* to think that something like functional reactive programming can simplify the usual GUI-widget object-and-callback mess. But I'm not sure the dust has settled from the various FRP paradigms figuring out what works, yet.

But I'd love it if, eg, something like Elm wasn't so narrow-focused to 'compiling to Javascript in a web page' and aimed a bit broader.