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
I am confused. 100 objects can as easily be created in one transaction
as in a hundred transactions, can they not?
Are you (John) trying to say that REST has some impact on a client's
ability to enclose 100 objects in one transaction? This may be true: I
have never tried big transactions over
I mistakenly wrote:
I am confused. 100 objects can as easily be created in one transaction
as in a hundred transactions, can they not?
...
Please ignore that message, which both represented my misunderstanding
of the HTTP PUT method, and did not take into account the full context
of the
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
Sorry we got into a big discussion about the web. I really want to discuss
POLs for rules, css being one of them. And in particular, once we have a
good POL, how to test it, and author with it--how to create a great POL
program?
But what about probablistic rules? Can we design an ultimate
I know of a few sites/tools which critcise your wesite...is there one for
css?
On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote:
Sorry we got into a big discussion about the web. I really want to
discuss POLs for rules, css being one of them. And in particular, once we
have a
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
I guess what I am asking for is a critic service. For both POLs and uses
of POLs. Can POLs be designed such that uses of POLs ensure good design?
Good architecture? I am way beyond my technical knowledge here.
On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote:
I know of a few
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
It seems this is not possible without a fitness function. A declarative
approach to defining the what of your program would probably go some way
towards making the validation of the how possible. BDD (behavior driven
development) is the closest approach I have found to this - however the
silver
Could the fitness function be # of recent users? Any other ideas?
On Feb 15, 2013 2:04 PM, shaun gilchrist shaunxc...@gmail.com wrote:
It seems this is not possible without a fitness function. A declarative
approach to defining the what of your program would probably go some way
towards
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
Can POLs be designed such that uses of POLs ensure good design? Good
architecture? I am way beyond my technical knowledge here.
Bad code can be written in any language, and even good code can be used to
develop bad ideas and architectures. You can't ever ensure good design,
not least of all
We have design guidelines. We have look and feel. The cell phone seems to
narrow down what is possible, pushing developers towards common metaphors.
There are app creation wizards for smartphones now. I think there may be a
turning point where people may start using wizards to create more apps.
I know a lot of programs collect usage statistics. Does # of times used
mean popular, good, or something that needs to be automated? I see your
point. We don't want to automate the back button yet.
On Feb 15, 2013 2:52 PM, David Barbour dmbarb...@gmail.com wrote:
Can POLs be designed such
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
Could one analyze the test code (not the main source code) assuming it is
complete enough and make a determination? That is, the style of testing
determines how good the main code is. Is there behavior driven development
for behavior driven development?
On Feb 15, 2013 2:04 PM, shaun gilchrist
I.e.: given new code is checked in
When code coverage is complete
And all tests succeed
Then deploy to integration
On Feb 15, 2013 3:30 PM, John Carlson yottz...@gmail.com wrote:
Could one analyze the test code (not the main source code) assuming it is
complete enough and make a determination?
There are people who do this sort of continuous deployment, and even swear
by it. I've not tried it, but I suppose it encourages development of good
tests and easily speeds up the feedback cycle. I've been thinking about
such approaches for Wiki-based development.
On Fri, Feb 15, 2013 at 2:04
32 matches
Mail list logo
