On 2013-02-14, at 07:52, Casey Ransberger casey.obrie...@gmail.com wrote:
The next big thing probably won't be some version of Minecraft, even if
Minecraft is really awesome. OTOH, you and your kids can prove me wrong today
with Minecraft Raspberry Pi Edition, which is free, and comes with
From: Jeff Gonis jeff.go...@gmail.commailto:jeff.go...@gmail.com
To: Alan Kay alan.n...@yahoo.commailto:alan.n...@yahoo.com
Cc: Fundamentals of New Computing fonc@vpri.orgmailto:fonc@vpri.org
Sent: Tuesday, February 12, 2013 10:33 AM
Subject: Re: [fonc] Terminology: Object Oriented vs Message
That's roughly accurate, and DIS doesn't really stand alone. The basic
model is as follows:
- DIS is used to support real-time simulation, most commonly of a
battlespace
- each simulator (e.g., a tank, an F16) maintains a local world model
(geodata, imagery) and it's own behavioral/physics
John Carlson wrote:
On Feb 13, 2013 7:57 PM, Miles Fidelman mfidel...@meetinghouse.net
mailto:mfidel...@meetinghouse.net wrote:
Ahh... but my argument is that the architecture of the current web
is SIMPLER than earlier concepts but has proven more powerful (or at
least more effective).
And of course, for some time there has been Croquet
http://en.wikipedia.org/wiki/Croquet_project
... and its current manifestation
http://en.wikipedia.org/wiki/Open_Cobalt
These are based on Dave Reed's 1978 MIT thesis and were first implemented about
10 years ago at Viewpoints.
Besides
Yes, uni-directional is simpler than bi-directional. The web doesn't
require configuration? You've got to be kidding. That's what juju charms
are for. I think minimal configuration on the client-side is what you are
referring to. I don't recall any client-side gopher configuration besides
Alan,
Any news if Open Cobalt supports auctions, banks, or ads yet?
Thanks,
John
On Thu, Feb 14, 2013 at 8:52 AM, Alan Kay alan.n...@yahoo.com wrote:
And of course, for some time there has been Croquet
http://en.wikipedia.org/wiki/Croquet_project
... and its current manifestation
That is, can one make money with Open Cobalt?
On Thu, Feb 14, 2013 at 9:17 AM, John Carlson yottz...@gmail.com wrote:
Alan,
Any news if Open Cobalt supports auctions, banks, or ads yet?
Thanks,
John
On Thu, Feb 14, 2013 at 8:52 AM, Alan Kay alan.n...@yahoo.com wrote:
And of course,
Note of warning from: http://en.wikipedia.org/wiki/Virtual_world
One example is that of Ginko
Financialhttp://en.wikipedia.org/wiki/Ginko_Financial,
a bank system featured in Second
Lifehttp://en.wikipedia.org/wiki/Second_Life where
avatars could deposit their real life currency after converted
On 2013-02-14, at 16:22, John Carlson yottz...@gmail.com wrote:
That is, can one make money with Open Cobalt?
I'm pretty sure you chose the wrong mailing list for this question.
- Bert -
___
fonc mailing list
fonc@vpri.org
John Carlson wrote:
Yes, uni-directional is simpler than bi-directional. The web doesn't
require configuration? You've got to be kidding. That's what juju
charms are for. I think minimal configuration on the client-side is
what you are referring to. I don't recall any client-side gopher
On Feb 14, 2013 12:52 PM, Miles Fidelman mfidel...@meetinghouse.net
wrote:
Well, at least in principle, drop an html file in a directory (behind a
server) and it gets served (or drop it in a WebDAV folder).
That sounds like the web circa 1993.
Again, you have to configure all the hyperlinks
John Carlson wrote:
On Feb 14, 2013 12:52 PM, Miles Fidelman mfidel...@meetinghouse.net
mailto:mfidel...@meetinghouse.net wrote:
Well, at least in principle, drop an html file in a directory
(behind a server) and it gets served (or drop it in a WebDAV folder).
That sounds like the web
PUTs, DELETEs require an id in the api, correct? Are you referring to
collection identifiers? I'm talking about uploading multiple JSON objects
to the server which can be done with http or REST, but http is preferred,
because there is a single round trip. And yes, there's JSON coming back
too
Perhaps. I believe for anything to truly succeed, it should support secure
commerce. Does the current text infrastructure support secure commerce?
Or are we lying to ourselves?
On Feb 14, 2013 12:10 PM, Bert Freudenberg b...@freudenbergs.de wrote:
On 2013-02-14, at 16:22, John Carlson
On Thu, Feb 14, 2013 at 1:01 PM, John Carlson yottz...@gmail.com wrote:
PUTs, DELETEs require an id in the api, correct? Are you referring to
collection identifiers? I'm talking about uploading multiple JSON objects
to the server which can be done with http or REST, but http is preferred,
What I am suggesting is using full http with json is superior to rest. For
your session id based puts, how are you accumulating errors? Or are you?
On Feb 14, 2013 3:26 PM, David Barbour dmbarb...@gmail.com wrote:
On Thu, Feb 14, 2013 at 1:01 PM, John Carlson yottz...@gmail.com wrote:
PUTs,
REST was a simplification of HTTP. I am merely reporting backlash against
REST. Also there is backlash against XML which is why people are using
JSON. There was probably quite a bit of design of HTTP, but I could see
MIME being replaced with something else.
Is there any truth to the rumor
Ummm, for the most part, REST = using HTTP as one's API (Roy Fielding
gives a far more detailed description in his thesis, where he coins the
term, http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf, but
as Roy was one of the authors of the HTTP spec, REST is really
descriptive of the
John Carlson wrote:
REST was a simplification of HTTP. I am merely reporting backlash
against REST. Also there is backlash against XML which is why people
are using JSON. There was probably quite a bit of design of HTTP, but
I could see MIME being replaced with something else.
Is there
Here's where I believe the issue lies: 1. Adding approximately 100 or more
objects to a collection backed by a relational database, in an interactive
system. I believe the time for the transaction(s) took too long. I am not
sure if the REST service supported by the database used a single
John Carlson wrote:
Here's where I believe the issue lies: 1. Adding approximately 100 or
more objects to a collection backed by a relational database, in an
interactive system. I believe the time for the transaction(s) took
too long. I am not sure if the REST service supported by the
Miles wrote:
For the most part, if you want to retrieve JSON data, you need to use
some protocol - the RESTful model is to address the data with a URL, and
use an HTTP GET. If you want to upload or replace some data, you use HTTP
PUT, and to delete it you use HTTP DELETE. That's about as simple
Not really obfuscating. Just trying to explain that 1 transaction is going
to work faster than 100 transactions. If you agree with that, I have no
problem. If not, you might also believe that putc performs as fast as
puts, which is wrong.
On Feb 14, 2013 4:59 PM, Miles Fidelman
On Thu, Feb 14, 2013 at 2:59 PM, John Carlson yottz...@gmail.com wrote:
Miles wrote:
For the most part, if you want to retrieve JSON data, you need to use
some protocol - the RESTful model is to address the data with a URL, and
use an HTTP GET. If you want to upload or replace some data,
You are speculating that it is too slow. Have you benchmarked it?
I didn't benchmark it. Someone else did. The bechmarking was done right as
I was joining the project. It's been a while. The database team
controlled the REST services at the time. I suspect, but am unsure, that
the REST
26 matches
Mail list logo
