On 6/14/2012 10:19 PM, John Zabroski wrote:
Folks,
Arguing technical details here misses the point. For example, a
different conversation can be started by asking Why does my web
hosting provider say I need an FTP client? Already technology is way
too much in my face and I hate seeing programmers blame their tools
rather than their misunderstanding of people.
Start by asking yourself how would you build these needs from scratch
to bootstrap something like the Internet.
What would a web browser look like if the user didnt need a seperate
program to put data somewhere on their web server and could just use
one uniform mexhanism? Note I am not getting into "nice to have"
features like resumption of paused uploads due to weak or episodic
connectivity, because that too is basically a technical problem -- and
it is not regarded as academically difficult either. I am simply
taking one example of how users are forced to work today and asking
why not something less technical. All I want to do is upload a file
and yet I have all these knobs to tune and things to "install" and
none of it takes my work context into consideration.
idle thoughts:
there is Windows Explorer, which can access FTP;
would be better if it actually remembered login info, had automatic
logic, and could automatically resume uploads, ...
but, the interface is nice, as an FTP server looks much like a
directory, ...
also, at least in the past, pretty much everything *was* IE:
could put HTML on the desktop, in directories (directory as webpage), ...
but most of this went away AFAICT (then again, not really like IE is
"good").
maybe, otherwise, the internet would look like local applications or
similar. they can sit on desktop, and maybe they launch windows. IMHO, I
don't as much like tabs, as long ago Windows basically introduced its
own form of tabs:
the Windows taskbar.
soon enough, it added another nifty feature:
it lumped various instances of the same program into popup menus.
meanwhile, browser tabs are like Win95 all over again, with the thing
likely to experience severe lag whenever more than a few pages are open
(and often have responsiveness and latency issues).
better maybe if more of the app ran on the client, and if people would
use more asynchronous messages (rather than request/response).
...
so, then, webpages could have a look and feel more like normal apps.
Why do I pay even $4 a month for such crappy service?
On Jun 11, 2012 8:17 AM, "Tony Garnock-Jones"
<tonygarnockjo...@gmail.com <mailto:tonygarnockjo...@gmail.com>> wrote:
On 9 June 2012 22:06, Toby Schachman <t...@alum.mit.edu
<mailto:t...@alum.mit.edu>> wrote:
Message passing does not necessitate a conceptual dependence on
request-response communication. Yet most code I see in the
wild uses
this pattern.
Sapir-Whorf strikes again? ;-)
I rarely
see an OO program where there is a "community" of objects who
are all
sending messages to each other and it's conceptually ambiguous
which
object is "in control" of the overall system's behavior.
Perhaps you're not taking into account programs that use the
observer/observable pattern? As a specific example, all the uses
of the "dependents" protocols (e.g. #changed:, #update:) in
Smalltalk are just this. In my Squeak image, there are some 50
implementors of #update: and some 500 senders of #changed:.
In that same image, there is also protocol for "events" on class
Object, as well as an instance of Announcements loaded. So I think
what you describe really might be quite common in OO /systems/,
rather than discrete programs.
All three of these aspects of my Squeak image - the "dependents"
protocols, triggering of "events", and Announcements - are
encodings of simple asynchronous messaging, built using the
traditional request-reply-error conversational pattern, and
permitting conversational patterns other than the traditional
request-reply-error.
As an aside, working with such synchronous simulations of
asynchronous messaging causes all sorts of headaches, because
asynchronous events naturally involve concurrency, and the
simulation usually only involves a single process dispatching
events by synchronous procedure call.
Regards,
Tony
--
Tony Garnock-Jones
tonygarnockjo...@gmail.com <mailto:tonygarnockjo...@gmail.com>
http://homepages.kcbbs.gen.nz/tonyg/
_______________________________________________
fonc mailing list
fonc@vpri.org <mailto:fonc@vpri.org>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
