On 6/9/2011 12:56 AM, Josh Gargus wrote:
On May 31, 2011, at 7:30 AM, Alan Kay wrote:
Hi Cornelius
There are lots of egregiously wrong things in the web design. Perhaps
one of the simplest is that the browser folks have lacked the
perspective to see that the browser is not like an application, but
like an OS. i.e. what it really needs to do is to take in and run
foreign code (including low level code) safely and coordinate outputs
to the screen (Google is just starting to realize this with NaCl
after much prodding and beating.)
I think everyone can see the implications of these two perspectives
and what they enable or block
Some of the implications, anyway. The benefits of the OS-perspective
are clear. Once it hits its stride, there will be no (technical)
barriers to deploying the sorts of systems that we talk about here
(Croquet-Worlds-Frank-OMeta-whatnot). Others will be doing their own
cool things, and there will be much creativity and innovation.
However, elsewhere in this thread it is noted that the HTML-web is
structured-enough to be indexable, mashupable, and so forth. It makes
me wonder: is there a risk that the searchability, etc. of the web
will be degraded by the appearance of a number of
mutually-incompatible better-than-HTML web technologies? Probably
not... in the worst case, someone who wants to be searchable can also
publish in the "legacy" format.
However, can we do better than that? I guess the answer depends on
which aspect of the status quo we're trying to improve on
(searchability, mashups, etc). For search, there must be plenty of
technologies that can improve on HTML by decoupling search-metadata
from presentation/interaction (such as OpenSearch, mentioned elsewhere
in this thread). Mashups seem harder... maybe it needs to happen
organically as some of the newly-possible systems find themselves
converging in some areas.
But I'm not writing because I know the answers, but rather the
opposite. What do you think?
hmm... it is a mystery....
actually, possibly a relevant question here, would be why Java applets
largely fell on their face, but Flash largely took off (in all its uses
from YouTube to "Punch The Monkey"...).
but, yeah, there is another downside to deploying ones' technology in a
browser:
writing browser plug-ins...
and, for browser-as-OS, what exactly will this mean, technically?...
network-based filesystem and client-side binaries and virtual processes?...
like, say, if one runs a tiny sand-boxed Unix-like system inside the
browser, then push or pull binary files, which are executed, and may
perform tasks?...
could be interesting though, as then a "tab" can be either an open page
or document, or a running application. hopefully, these could be nicer
to target, and more capable, than either Flash or Java Applets, although
probably would require some sort of VM.
"NaCl" is not a perfect solution, if anything, because, say, x86 NaCl
apps don't work on x86-64 or ARM. nicer would be able to be able to run
it natively, if possible, or JIT it to the native ISA if not.
I did my own x86-based VM before, which basically just ran x86 in an
interpreted (via translation to threaded code) environment. technically,
I just sort of did a basic POSIX-like architecture, albeit I used
PE/COFF for binaries and libraries (compiled via MinGW...).
it was written in such a way that likely it wont care what the host
architecture is (it was all plain C, with no real ASM or
architecture-specific hacks...).
so, I guess, if something like this existed inside a browser, and was
isolated from the host OS?...
in my case, I wrote the VM and soon realized I personally had no
particular use for it...
and, meanwhile, for my own site, it is generally plain HTML...
I did basic CGI-scripts before as a test, but couldn't think up much to
use them for (I don't personally really do much of anything that really
needs CGI-scripts).
about the most I would likely do with it would be to perform simple
surveys, say, a form that is like:
"favorite programming language?", "MBTI type?", ...
then I could analyze the results to conclude which types of personality
are more associated with being a programmer, and which prefer which
sorts of programming languages, ...
for example... how common are other xSTP (ISTP or ESTP) programmers, and
how many like C?...
in general though, I use HTML for much of my documentation, but
generally because it is currently one of the least-effort ways to
provide structured and formatted documentation and have it be readily
accessible (online or offline).
at least, currently I use SeaMonkey Composer, which is not that much
more effort than using a word-processor, and IMO a little less silly in
terms of how it behaves (vs Word or OpenOffice Writer which seem at
times brain-damaged...). not that Composer is perfect either though.
for editing documentation, a WYSIWYG editor works fine, since ones' goal
is more to just produce generally formatted and structured text, rather
than needing much fine-grained control.
although, if possible, something more Wiki-like could be nicer still,
but WikiML lacks any real WYSIWYG editors AFAICT, and would need to be
converted to HTML prior to passing off to a client or web-browser,
creating a problem for local offline display (one either needing a
specialized viewer, or a local webserver daemon, with the browser as the
UI).
so, flat HTML would seem to be the least effort strategy.
I have before considered the possibility of using a WikiML variant in
documentation comments, as an alternative to Javadoc/Doxygen style
documentation comments (or XML documentation comments...). sadly, I
never got around to this...
I have an older documentation system, but it sucked and has long since
fallen into disuse (too much information needed to be present in the
comments, ...).
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
