John Carlson wrote:
The way I read rest over http post (wikipedia) is that you either
create a new entry in a collection uri, or you create a new entry in
the element uri, which becomes a collection. So one still needs a way
to add several entries to a collection, or one needs something
On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote:
I can't say anything about REST in general being slow. I would like to see
better support for adding multiple objects to a collection in HTTP REST,
perhap by using MIME.
REST is not a highly efficient protocol by any
On Fri, Feb 15, 2013 at 12:10 AM, John Carlson yottz...@gmail.com wrote:
The way I read rest over http post (wikipedia) is that you either create a
new entry in a collection uri, or you create a new entry in the element
uri, which becomes a collection.
There are other options. For example, if
If you have to start a new relational database transaction for each http
post when submitting hundreds of posts, that's going to create a lot of
overhead, if you choose to use session ids and leave the tranaction open,
then you risk not committing something. If you use database pools, you are
On Fri, Feb 15, 2013 at 12:56 AM, J. Andrew Rogers and...@jarbox.orgwrote:
REST is not a highly efficient protocol by any means
Indeed. REST isn't even a protocol.
The largest total consumer of CPU time [.. is ..] parsing JSON source
formats
While this is a good point, it isn't clear to
Andrew,
J. Andrew Rogers wrote:
On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote:
I can't say anything about REST in general being slow. I would like to see
better support for adding multiple objects to a collection in HTTP REST, perhap
by using MIME.
REST is not a
On Fri, Feb 15, 2013 at 1:22 AM, John Carlson yottz...@gmail.com wrote:
If you have to start a new relational database transaction for each http
post when submitting hundreds of posts, that's going to create a lot of
overhead, if you choose to use session ids and leave the tranaction open,
The most important paragraph is at the bottom.
It depends on the implementation of PUT. If it's implemented as a delete
followed by an insert, then it's likely you've lost data like created
date, unless you write some clever triggers.
If it's implemented as an update then there's also a chance
The last they should be POSTs.
Forgive my typos. For some unknown reason I am using my phone
On Feb 15, 2013 3:52 AM, John Carlson yottz...@gmail.com wrote:
The most important paragraph is at the bottom.
It depends on the implementation of PUT. If it's implemented as a delete
followed by
J. Andrew Rogers and...@jarbox.org writes:
On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote:
REST is commonly used to transport XML or JSON or similar. Parsing
JSON or XML encoding structures is quite slow because they are
intrinsically inefficient as wire encoding formats.
On Fri, Feb 15, 2013 at 1:52 AM, John Carlson yottz...@gmail.com wrote:
I believe the best thing to do is use POST to create objects and quit
trying to fool people with your smartness. You're only asking for trouble
if you do otherwise.
Ah, the people are too dumb to understand anything but
The most valuable part of the POST is the database generated ID. I realize
there are other ways to do this--batching the creation of IDs for example.
One needs IDs before doing PUTs and GETs. Yes I understand the value of
obfuscating IDs for security reasons. I don't really agree with showing
On Feb 15, 2013, at 1:41 AM, David Barbour dmbarb...@gmail.com wrote:
A technique I've seen used (albeit, only once or twice) is to batch updates
from multiple connections, and run batches at 20+Hz while there is demand for
them. This only requires one connection from the server to its
On Fri, Feb 15, 2013 at 10:30 AM, John Carlson yottz...@gmail.com wrote:
The most valuable part of the POST is the database generated ID. I
realize there are other ways to do this--batching the creation of IDs for
example. One needs IDs before doing PUTs and GETs.
I generally favor
Thank you. I was not aware of the terminology surrounding this technique or
the current work on it.
On Fri, Feb 15, 2013 at 10:34 AM, J. Andrew Rogers and...@jarbox.orgwrote:
On Feb 15, 2013, at 1:41 AM, David Barbour dmbarb...@gmail.com wrote:
A technique I've seen used (albeit, only
I think you're missing the point that some people prefer reading code over
documentation. If your code is literate and uses common conventions and
doesn't surprise the maintainer isn't that a good thing? I recall someone
showing me an infinite loop in the linux kernel. He was surprised. So
if
I am against showing ids to the end user. With rest you can do a get on a
collection uri and see all the entry ids.
On Feb 15, 2013 1:33 PM, David Barbour dmbarb...@gmail.com wrote:
On Fri, Feb 15, 2013 at 10:30 AM, John Carlson yottz...@gmail.com wrote:
The most valuable part of the POST is
On Fri, Feb 15, 2013 at 11:51 AM, John Carlson yottz...@gmail.com wrote:
I am against showing ids to the end user. With rest you can do a get on a
collection uri and see all the entry ids.
A big aspect of REST architectural style is the ability to distribute
resource identifiers with other
On Feb 15, 2013, at 1:31 AM, Miles Fidelman mfidel...@meetinghouse.net wrote:
As a practical matter, most people that use REST use JSON or XML and most
people that don't use JSON and XML also don't use REST for related reasons.
But it is not fair to blame REST for what is primarily an issue
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).
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
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
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
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
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
to allow all in the world to make their own media and have it used by
others ...
Cheers,
Alan
From: John Carlson yottz...@gmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Tuesday, February 12, 2013 9:00 PM
Subject: [fonc] Design of web, POLs
--
*From:* John Carlson yottz...@gmail.com
*To:* Fundamentals of New Computing fonc@vpri.org
*Sent:* Tuesday, February 12, 2013 9:00 PM
*Subject:* [fonc] Design of web, POLs for rules. Fuzz testing nile
Although I have read very little about the design of the web
of New Computing
fonc@vpri.org
Sent: Wednesday, February 13, 2013 7:44 AM
Subject: Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
Alan --
Yes, we seem to slowly getting back the the NeWS (Network extensible Windowing
System) paradigm which used a modified Display Postscript
I've done some postscript programming. I guess I see the shading languages
more a successor to postscript than any revival of display postscript and
its onerous licensing. People are already trying to put javascript into
the gpu. I haven't seen nile, but I assume that it works with gpus. What
Alan Kay wrote:
Or you could look at the actual problem a web has to solve, which is
to present arbitrary information to a user that comes from any of
several billion sources. Looked at from this perspective we can see
that the current web design could hardly be more wrong headed. For
@vpri.org
Sent: Wednesday, February 13, 2013 4:58 PM
Subject: Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
Alan Kay wrote:
Or you could look at the actual problem a web has to solve, which is to
present arbitrary information to a user that comes from any of several
billion
Hi Alan
First, my email was not about Ted Nelson, Doug Engelbart or what
massively distributed media should be like. It was strictly about
architectures that allow a much wider range of possibilities.
Ahh... but my argument is that the architecture of the current web is
SIMPLER than
On Feb 13, 2013 7:57 PM, Miles Fidelman 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).
If you believe that, I've got a perl script I want to sell
, 2013 5:56 PM
Subject: Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
Hi Alan
First, my email was not about Ted Nelson, Doug Engelbart or what massively
distributed media should be like. It was strictly about architectures that
allow a much wider range of possibilities.
Ahh
Although I have read very little about the design of the web, things are
starting to gel in my mind. At the lowest level lies the static or
declarative part of the web. The html, dom, xml and json are the main
languages used in the declarative part. Layered on top of this is the
dynamic or
43 matches
Mail list logo
