On 11/5/2013 7:15 AM, Miles Fidelman wrote:
Casey Ransberger casey.obrien.r at gmail.comwrites
<mailto:fonc%40vpri.org?Subject=Re%3A%20%5Bfonc%5D%20Task%20management%20in%20a%20world%20without%20apps.&In-Reply-To=%3CDD90A941-C94A-4F01-A013-6D838B0B2524%40gmail.com%3E>
A fun, but maybe idealistic idea: an "application" of a computer
should just be what one decides to do with it at the time.
I've been wondering how I might best switch between "tasks" (or
really things that aren't tasks too, like toys and documentaries and
symphonies) in a world that does away with most of the application
level modality that we got with the first Mac.
The dominant way of doing this with apps usually looks like either
the OS X dock or the Windows 95 taskbar. But if I wanted less shrink
wrap and more interoperability between the virtual things I'm
interacting with on a computer, without forcing me to "multitask"
(read: do more than one thing at once very badly,) what's my best
possible interaction language look like?
I would love to know if these tools came from some interesting
research once upon a time. I'd be grateful for any references that
can be shared. I'm also interested in hearing any wild ideas that
folks might have, or great ideas that fell by the wayside way back when.
For a short time, there was OpenDoc - which really would have turned
the application paradigm on its head. Everything you interacted with
was an object; with methods incorporated into it's "container." E.g.,
if you were working on a "document," there was no notion of a word
processor, just the document with embedded methods for interacting
with it.
a while ago, I had started, but didn't finish writing (or at least to a
level I would want to send it) about the relationship between
object-based and dataflow-based approaches to modular systems (where in
both cases, the "application" could be largely dissolved in favor of
interacting components and "generic" UIs).
but, the line gets kind of fuzzy, as what people often call "OOP"
actually covers several distinct sets of methodologies, and people so
much often focus on lower-level aspects (class vs not-a-class,
inheritance trees, ...), that there is a tendency to overlook
higher-level aspects, like whether the system is composed of objects
interacting via passing messages using certain interfaces, or whether it
is working with a data-stream where the objects don't really interact at
all and rather produce and consume data in a set of shared representations.
then, there is the "bigger" issue from an architectural POV, namely, can
"App A access anything from within App B?" short of both developers each
having access to and the ability to hack on each-others' source code
(or, often, get the thing rebuilt from source sometimes).
so, we have some problems:
lack of shared functionality (often short of what has explicitly been
made into shared libraries or similar);
frequent inability to add new functionality to existing apps (or "UIs"),
short of having access to and ability to modify their source-code to
ones uses;
lots of software that is a PITA to get to rebuild from source (*1);
...
*1: especially in GNU land, where they pride themselves of freely
available source, but the ever present GNU Autoconf system has a problem:
it very often has a tendency not to work;
it is often annoyingly painful to get it to work when it has decided it
doesn't want to;
very often developers set some rather arbitrary restrictions on projects
build-probing, like "must have exactly this version of this library to
build", even when it will often still build and work with later (and
earlier) versions of the library;
...
it is sad, in premise, that hard-coded Visual Studio projects, and raw
Makefiles, are often easier to get to work when things don't go "just
right". well, that and one time recently managing to apparently get on
the bad side of some developers for a FOSS GPL project, by going and
building part of it using MSVC (for plugging some functionality into the
app), but in this case, it was the path of least effort (the other code
I was using with it was already being built with MSVC, and I couldn't
get the main project to rebuild from source via the "approved" routes
anyways, ...).
weirder yet, some of the better development experiences I have had have
been in developing extensions for closed-source commercial projects
(without any ability to see their source-code, or for that matter, even
worthwhile API documentation), which "should not be".
not that I don't think these problems are solvable, but maybe the
"spaghetti string mess" that is GNU-land at present isn't really an
ideal solution. like, there might be a need to address "general
architectural issues" (provide solid core APIs, ...), rather than just
daisy-chaining everything in a somewhat ad-hoc manner.
but, as an assertion:
with increasing modularity and ability to share functionality between
apps, and to extend preexisting apps with new functionality (via
plugin-like interfaces), potentially the significance of big monolithic
applications would go into decline (things become less app-centric and
more task-centric).
granted, it would also require an shift in focus:
rather than an application being simply a user of APIs and resources, it
would instead need to be a "provider" of an interface for other
components to reuse parts of its functionality and APIs, ideally with
some decoupling such that neither the component nor the application need
to be directly aware of each other.
so, the component exports a service;
the application uses the service;
the two seemingly "merge", using the functionality provided by one of
them, and the UI by the other.
sort of like codecs on Windows: you don't have to go write a plugin for
every app that uses media (or, worse, hack on their code), nor does
every media player or video-editing program have to be aware of every
possible codec or media container format, they seemingly, "just work",
you install the appropriate drivers and it is done.
the GNU-land answer more tends to be "we have FFmpeg / libavcodec and
VLC Media Player", then lots of stuff is built by building lots of
things on top of these, which isn't quite the same thing (you need to
deal with one or both to add a new codec, hacking code into and
rebuilding libavcodec, or modifying or plugging into VLC to add support,
...).
nevermind if writing things like codec drivers for Windows isn't such a
great experience either.
stuff "could be better" in any case...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
