Hi,

On 10/14/07, collin_jackson <yahoo@...> wrote:
> --- In json@yahoogroups.com, "Michael Schwarz" <michael.schwarz@...>
> wrote:
> > Some other questions while implementing a client plugin:
>
> Can you tell us which platform you are developing a client plugin for?

I write one for Mac and Windows, well, it is not a real plugin, but a
way to integrate it in you web pages.



> > Why only send the domain, doesn't the complete Uri makes sence?
>
> The browser's security policy isn't granular enough to separate URIs
> into separate security contexts, so it would be easy for a site to
> spoof any URI within the page's a given domain by injecting script
> tags into other pages. Also, in Firefox (for example) there are many
> scenarios where a page has URI that does not specify a domain
> (about:blank, or a javascript: URI) yet the page does have a domain
> according to the browser.
>

What I thought was pages like aol.com/users/xxxx or
t-online.de/home/xxxx. Where is the "domain" specified, I thought it
will use the Web browsers location always, which in my mind is not
speficic enough.

Michael



> To make this header match the browser's security policy, it would be
> possible to set a header of the form scheme://domain:port (with no
> path included), but I'm not sure whether this is necessary.
>
>



--
Best regards | Schöne Grüße
Michael

Microsoft MVP - Most Valuable Professional
Microsoft MCAD - Certified Application Developer

http://weblogs.asp.net/mschwarz/
http://www.ajaxpro.info/

Skype: callto:schwarz-interactive
MSN IM: passport@...

Hello all,

http://lloydforge.org/projects/yajl/

This is a fast, lightweight, portable JSON
parsing/generation/validation library.  It's design goals were to
provide fast stream based event driven parsing that is representation
agnostic.

The concrete problem that motivated it's creation was that often I'm
using JSON in network protocols, and in performance critical
situations it's suboptimal to A) wait for all the data to arrive
before we start parsing, and B) map everything into the data
representation that the parsing library provides, then re-map it into
the representation of the application that embeds the library.

Aside from these performance related edge cases, I hope it's something
that's generally applicable.  It also comes with a command line json
validator and json pretty printer/minimizer.

Finally, it's possible to write small libraries on top of yajl which
provide a convenient data representation.

I'm interested in hearing all bug reports, and know there are
currently a couple open issues (heard a complaint that the parser is
too lenient on accepting invalid UTF-8 inside strings).

Also, if anyone is interested in helping me build MacPorts/FreeBSD
ports/RPMs for this thing, please holler.  I'd love the help.

hope this is useful,
lloyd hilaiel

The original version of json.js had a JSON object containing stringify
and parse methods. When the opportunity to add JSON support to the
next proposed standard for ECMAScript, the methods changed to toString
and parseJSON.

In retrospect, I think the original form was better. I have posted
json2.js which has JSON.stringify (which looks for the presence of a
toJSON method in the objects it stringifies), and JSON.parse (which
can still accept a filter function).

http://www.JSON.org/json2.js

I've been using my C# JSON parser for about a year now as I've been
building out a larger end-to-end Ajax framework.  Last week, I released
the JSON parser which the framework is built upon.

The parser/serializer is written in C# and is intended to be as easy to
use as XML serialization in .NET.  It includes the option to control
serialization using attributes or implementing an interface.  It has
the ability to serialize and deserialize strongly-typed classes.

Until the entire framework is available, I encourage you to try out the
parser:

     http://jsonfx.net/BuildTools/

Thanks,
Stephen McKamey

I for one totally agree with the decision to revert to the original API.
While I know that defensive enumeration is good practice, I really
appreciate keeping an unpolluted Object.prototype and Array.prototype. Thank
you Douglas, I think that was a good decision!
Kris


[Non-text portions of this message have been removed]

Thank you for implmenting this.  this make the code so much cleaner.

Now if we can just get the Prototype library to stop overloading
Object....

--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The original version of json.js had a JSON object containing
stringify
> and parse methods. When the opportunity to add JSON support to the
> next proposed standard for ECMAScript, the methods changed to
toString
> and parseJSON.
>
> In retrospect, I think the original form was better. I have posted
> json2.js which has JSON.stringify (which looks for the presence of
a
> toJSON method in the objects it stringifies), and JSON.parse (which
> can still accept a filter function).
>
> http://www.JSON.org/json2.js
>

Great job, Douglas.

There is a typo in the initial multiline comment at line 57, it says
JON.parse

On 10/30/07, Ric Johnson <RicJohnsonIII@...> wrote:
>
>   Thank you for implmenting this. this make the code so much cleaner.
>
> Now if we can just get the Prototype library to stop overloading
> Object....
>
> --- In json@yahoogroups.com <json%40yahoogroups.com>, "Douglas Crockford"
> <douglas@...> wrote:
> >
> > The original version of json.js had a JSON object containing
> stringify
> > and parse methods. When the opportunity to add JSON support to the
> > next proposed standard for ECMAScript, the methods changed to
> toString
> > and parseJSON.
> >
> > In retrospect, I think the original form was better. I have posted
> > json2.js which has JSON.stringify (which looks for the presence of
> a
> > toJSON method in the objects it stringifies), and JSON.parse (which
> > can still accept a filter function).
> >
> > http://www.JSON.org/json2.js
> >
>
>
>



--
Blog: http://justavo.blogsome.com/


[Non-text portions of this message have been removed]

What would be the recommended way of converting the result of an
regexp.exec(str) method call to JSON? The result is an array but with
two extra properties; index and input.

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Glob
al_Objects:RegExp:exec

If I use stringify then I just get the array elements and the index
and input properties are missing. Is there a way of tricking the
stringify function into treating this as an object rather than an
array so I can get all the elements/properties/values?

--- In json@yahoogroups.com, "Jim Fricker" <yahoo@...> wrote:
>
> What would be the recommended way of converting the result of an
> regexp.exec(str) method call to JSON? The result is an array but with
> two extra properties; index and input.
>
> If I use stringify then I just get the array elements and the index
> and input properties are missing. Is there a way of tricking the
> stringify function into treating this as an object rather than an
> array so I can get all the elements/properties/values?


myObject = {index: myArray.index, input: myArray.input, array: myArray};
jsontext = JSON.stringify(myObject);

Quick note: there is a new JSON processor (parser, generator, simpler
mapping tools) written in Java called Jackson.

It's available from:

http://www.cowtowncoder.com/hatchery/jackson/index.html

and dual-licensed under either ASL or LGPL.

I have also done some performance benchmarking using Japex performance
test suite, using other existing json implementations I was able to
find. If anyone is interested in those, this blog entry has links to
results and source code:

http://www.cowtowncoder.com/blog/archives/2007/10/entry_50.html

-+ Tatu +-

--- In json@yahoogroups.com, "Frans Thamura" <frans@...> wrote:
>
> hi all
>
> i am seeking an Java based of JSON that can convert JSON become URL,
>
> this is called URLEncoder and URLDecoder,
>
> anyone have it?

How would it do this? Using naming convention to map JSON elements
into URL query parameters? ( { "value" : { "a" : 1, "b" : "abc" } ->
http://...?value.a=1&value.b=abc ?)

If so, that'd be a useful mapping tool, and one not too difficult to
write.

-+ Tatu +-

In my search for a convenient way to represent XHTML DOM elements, I
assembled some ideas of how to apply the native JavaScript objects to
the W3C DOM objects.  I call this assembly of ideas JSoda.

JSoda is JSON compliant <http://jsoda.info/JSoda+and+JSON> , so that a
DOM element represented as a JSoda object can be stored or transmitted
as JSON and utilize existing JSON solutions.

The details are located at http://jsoda.info/ <http://jsoda.info/> .
The site also contains an MIT licensed script
<http://jsoda.info/Object.toDOM#script>  for parsing JSoda objects into
their DOM counterparts.  A simple (X)HTML to JSoda converter
<http://jsoda.info/DOM+to+JSoda>  is also provided.

JSON-related comments or suggestions can be made in reply to this post.
If you have any input that is not JSON related, such as problems with
the site or JSoda improvement suggestions, please send an email to
notalanguage at jsoda dot info.

Looking forward to your feedback!


[Non-text portions of this message have been removed]

Those interested in JSoda should also check out JsonML.  JsonML is a
more compact representation and is fast for converting any XML to JSON.

Example client scripts and XSLT are available at: http://jsonml.org

IBM developerWorks wrote an excellent tutorial:
http://www.ibm.com/developerworks/library/x-jsonml/

Coming soon is an Ajax framework which has native JsonML support for
ASP.NET: http://jsonfx.net/Architecture/

--- In json@yahoogroups.com, "Kyle Alan Hale" <kylealanhale@...> wrote:
>
> In my search for a convenient way to represent XHTML DOM elements, I
> assembled some ideas of how to apply the native JavaScript objects to
> the W3C DOM objects.  I call this assembly of ideas JSoda.

Indeed, JSoda and JsonML serve much the same purpose, but with
slightly different styles and goals.

> JsonML is a more compact representation

This is probably the best reason to choose Stephen's JsonML over
JSoda.  A JSoda object is much more verbose by design, which has some
readability and usability advantages over JsonML.. but it also takes
up more space/bandwidth.  There are several other reasons
<http://jsoda.info/JSoda+is#an+answer+to+jsonml> why I formulated
JSoda, rather than just using JsonML, but if those reasons aren't
issues for you, JsonML will save you some bandwidth.

On Nov 14, 2007 12:01 AM, Kyle Alan Hale <kylealanhale@...> wrote:
>
> In my search for a convenient way to represent XHTML DOM elements, I
>  assembled some ideas of how to apply the native JavaScript objects to
>  the W3C DOM objects. I call this assembly of ideas JSoda.
>
>  JSoda is JSON compliant <http://jsoda.info/JSoda+and+JSON> , so that a
>  DOM element represented as a JSoda object can be stored or transmitted
>  as JSON and utilize existing JSON solutions.

I may be bit slow, but I am not sure I understand why you would want
to wrap DOM within JSON?
Why not deal with xml via DOM as is? And when transferring, let
efficient xml generators/parsers take care of marshalling aspects?

I do understand the interoperability aspects sometimes require one to
use mappings to make things work (albeit inefficiently or awkwardly),
but are there some other benefits?

-+ Tatu +-

> I may be bit slow, but I am not sure I understand why you would want
> to wrap DOM within JSON?
> Why not deal with xml via DOM as is? And when transferring, let
> efficient xml generators/parsers take care of marshalling aspects?
>
> I do understand the interoperability aspects sometimes require one to
> use mappings to make things work (albeit inefficiently or awkwardly),
> but are there some other benefits?
>
> -+ Tatu +-
>

The DOM element objects themselves aren't being wrapped in JSON.  In
fact, JSoda isn't JSON at all, it's just nested JavaScript objects.
Each object type represents a different thing:

Object object -> DOM element
Array object -> DOM document fragment
String object -> DOM text node

However, it is JSON compliant, meaning that you can conveniently store
or transmit representations of DOM via, say, JSON RPC, or the proposed
JSONRequest, or any other method of transmitting textual information.
So, if you're using JSON anyway to transmit data, a JSoda object
could be embedded within the JSON text and not cause any problems with
JSON parsers... and not need an additional XML parser. In my case,
I'll be using it to transmit XHTML-based rich-text.. and I didn't want
to use a full fledged xml solution.  I may change my mind about that
as the project that I'm working on develops, but for now this is perfect.

I also use JSoda objects to build DOM elements, using the script
available on the site.  Sure, I could do everything in XHTML and
innerHTML it into my doc, but I'd rather be as ready for the future as
possible by implementing a wrapper around standards-based DOM methods.
Or, I could use XML and parse it, but the parsing overhead of a
native JavaScript object based solution is almost nonexistent,
compared to the intrinsically bulky XML parsers out there.

ha.. I didn't expect anyone to ask "Why not just use XML?" in the JSON
group.  If I were intending for this to be a markup language in
itself, then, you're right, XML would be more appropriate.  But JSoda
is just representing one language (XHTML) in terms of another
(JavaScript).  I like being able to think of DOM nodes as JavaScript
objects when working on JavaScript/AJAX based applications, but I
don't like the tedium of using the DOM functions on their own.  JSoda
meets both needs with a syntax that is analogous to DOM objects, but a
hell of a lot easier to build.

On Nov 14, 2007 12:41 PM, Kyle Alan Hale <kylealanhale@...> wrote:
> > I may be bit slow, but I am not sure I understand why you would want
>  > to wrap DOM within JSON?
>  > Why not deal with xml via DOM as is? And when transferring, let
>  > efficient xml generators/parsers take care of marshalling aspects?
>  >
>  > I do understand the interoperability aspects sometimes require one to
>  > use mappings to make things work (albeit inefficiently or awkwardly),
>  > but are there some other benefits?
>
>  The DOM element objects themselves aren't being wrapped in JSON. In
>  fact, JSoda isn't JSON at all, it's just nested JavaScript objects.
>  Each object type represents a different thing:
>
>  Object object -> DOM element
>  Array object -> DOM document fragment
>  String object -> DOM text node

Ah ok. So it's more about javascript objects, not so much about json per se?
If so, it is also related to methods like Badgerfish, which likewise
allows dealing with xml data by converting it to a more palatable
structure. :-)

Thanks!

-+ Tatu +-

I have been able to do some very interesting performance comparisons,
but unfortunately data I am using is company internal, and hence non
publishable. So I was wondering if anyone is aware of public domain
test data either already in json format (or in some simple wrapper
that can be mechanically translated to 'native' json, i.e. not using
mappings that add alien concepts like xml namespaces)?
I wasn't able to find any obvious candidates by googling (was earlier
hoping to find some data for large-scale correctness testing for
Jackson json parser), but perhaps someone on the list would know of
repositories?

-+ Tatu +-

> Ah ok. So it's more about javascript objects, not so much about json
per se?
> If so, it is also related to methods like Badgerfish, which likewise
> allows dealing with xml data by converting it to a more palatable
> structure. :-)
>
> Thanks!
>
> -+ Tatu +-
>

Yes, much like Badgerfish, just not as comprehensive.. but a bit
easier to read. Badgerfish is ideal for representing any XML-based
data.  JSoda is a simple alternative for storing XHTML (by utilizing
my toJSoda() function), and for quickly building DOM nodes with
toDOM().  The format of JSoda, though, has the same aim as Badgerfish:
JSON compatibility.

I wanted to introduce my project Persevere, as I have just released a new
version of the Persevere server and client:
http://code.google.com/p/persevere-framework/

Persevere is an open source set of tools for persistence and distributed
computing using simple intuitive JSON <http://www.json.org/> interchange
using HTTP REST <http://code.google.com/p/persevere-framework/wiki/RestJson>and
JSON-RPC <http://code.google.com/p/persevere-framework/wiki/JsonRpc>. The
Persevere project includes a Persevere Server and Persevere JavaScript
Client, but these interact through standard
REST<http://code.google.com/p/persevere-framework/wiki/RestJson>and
JSON-RPC <http://code.google.com/p/persevere-framework/wiki/JsonRpc>, and so
both the client and server can be used with other client and server
technologies.

The Persevere Server is a Java based server that provides persistent data
storage of JSON data, as well as query capability through
JSONPath<http://goessner.net/articles/JsonPath/>,
and distributed computing capabilities through JSON-RPC. Persevere follows
the JSPON <http://www.jspon.org/> convention for exposing persistent data
storage as JSON REST web services, and with full capabilities for
modification of persisted data, execution of remote/distributed JavaScript
methods on the client and server, and data centric object level security.
Persevere JavaScript Client is a persistent object mapping framework for
JavaScript in the browser, which allows programmers to access, traverse, and
manipulate persisted objects graphs easily with standard JavaScript syntax.
Complex dynamic object graphs can be persisted with Persevere (like JsonML).
You can see an example of creating a blog with persistence enabled
JavaScript:
http://www.ibm.com/developerworks/java/library/wa-aj-objmap/

I would love to get feedback on this. Persevere has been designed to use
simple standards based HTTP JSON communication for maximum interoperability.
If anyone is working on similar projects, I would be eager to see if there
are any interoperability opportunities between our projects. I have already
been doing some work to try to make it work with ActiveResource.
Thank you,
Kris


[Non-text portions of this message have been removed]

Hi Everyone
I was looking for a JSON serializer library to use in our web
application. I believe there are just too many options out there...
XStream, JSON-lib , FlexJson , DWR , JSON-RPC and so on.

I have looked at XStream and JSON-lib. Does anyone know which is the
best out there keeping in mind that JSON serialization can have
problems due to circular references and large object graphs.
Thanks
Haritha

You might want to check out jabsorb (formerly known as JSON-RPC-Java) at
http://jabsorb.googlecode.com

In the new 1.2 version, we've added circular reference and duplicate
reference support (1.2 is currently a release candidate, but the final
version is imminent...)

See also, http://code.google.com/p/jabsorb/wiki/CircularReferences for more
info about the circular references support and how it is implemented in
jabsorb.


On Nov 19, 2007 8:06 PM, haritha.juturu <haritha.juturu@...> wrote:

>   Hi Everyone
> I was looking for a JSON serializer library to use in our web
> application. I believe there are just too many options out there...
> XStream, JSON-lib , FlexJson , DWR , JSON-RPC and so on.
>
> I have looked at XStream and JSON-lib. Does anyone know which is the
> best out there keeping in mind that JSON serialization can have
> problems due to circular references and large object graphs.
> Thanks
> Haritha
>
>
>


[Non-text portions of this message have been removed]

> I was looking for a JSON serializer library to use in our web
> application. I believe there are just too many options out there...

There are far too many options.  It's because JSON is a wonderful new
emerging standard, and everyone wants a piece of the pie.. everyone
wants their names in the history books.  And, everyone has different
styles and needs.  So, there's no easy way out: you just have to
research every one of them and find the one that best meets your
needs.  The solutions that meet the needs of the most people will be
the ones to survive.  That's exactly why JSON is doing so well.

--- In json@yahoogroups.com, "Kyle Alan Hale" <kylealanhale@...> wrote:
>
> > I was looking for a JSON serializer library to use in our web
> > application. I believe there are just too many options out there...
>
> There are far too many options.  It's because JSON is a wonderful new
> emerging standard, and everyone wants a piece of the pie.. everyone
> wants their names in the history books.  And, everyone has different
> styles and needs.  So, there's no easy way out: you just have to
> research every one of them and find the one that best meets your
> needs.  The solutions that meet the needs of the most people will be
> the ones to survive.  That's exactly why JSON is doing so well.
>

Thanks All. guess i'll be playing with some of the libraries to decide
on what will work best.

I have been looking for some slightly complicated samples for json to
java objects conversion using JSON-LIB but in vain. So i thought i
will post my sample here to know if i am doing the right thing or
theres a simpler way to serialize json to java. I have given both the
json string and java code snippet. Please have a look and send in your
comments.

This is my JSON string

{
"name":"Nameless One",
"pages":[
{"name":"Page1",
"canvas":"{"objectType":"EditorCanvas",
"id":"editorCanvas",
"name":"",
"sizeWidth":940,
"cssClass":"",
"style":"width:940px;",
"children":[
		 {"objectType":"TextObject",
		 "id":"Text_1196907790312",
		 "name":"",
		 "cssClass":"",
		 "style":"left:40px;top:60px;width:620px;height:100px;",
		 "text":""[Winning the Nobel Peace Prize] brings the floodlight for
attention from the whole world right to one person, so the whole
world's watching you, what you're doing, what you're saying. So in a
way it's exciting, very exciting thing, but at the same time it's an
opportunity, opportunity to bring out the issues that I have been
raising for years. Sometimes felt that nobody was paying any
attention, like I've been screaming and nobody's hearing me. Now
suddenly this prestigious prize comes, and you get a feeling that you
can whisper, the whole world listens. This is your time to say what
you wanted to say." —Mohammad Yunus"},

		 {"objectType":"ImageObject",
		 "id":"Image_1196907800312",
		 "name":"",
		 "position":({left:40, top:220}),
		 "size":({width:300, height:300}),
		 "cssClass":"",
		 "style":"left:40px;top:220px;width:300px;height:300px;",
		 }
	 ]
}"
}
]
}

JSON json = JSONSerializer.toJSON(jsonStr);
//where jsonStris the one above
MorpherRegistry morpherRegistry = new MorpherRegistry();
		 morpherRegistry.registerMorpher( new BeanMorpher( BaseObject.class,
morpherRegistry));
		 morpherRegistry.registerMorpher( new BeanMorpher(
SplashNoteObject.class, morpherRegistry));
		 morpherRegistry.registerMorpher( new BeanMorpher( PageObject.class,
morpherRegistry));
		 morpherRegistry.registerMorpher( new BeanMorpher(
EditorCanvas.class, morpherRegistry));

SplashNoteObject snObject = (SplashNoteObject) JSONObject.toBean(
(JSONObject) json, SplashNoteObject.class );
PageObject page =
(PageObject)morpherRegistry.morph(PageObject.class,snObject.getPages().get(0));

EditorCanvas bean = (EditorCanvas)page.getCanvas();
//i havent included the code for any further levels like TextObject
and ImageObject

Is this the only was i can serialize json to java objects. Do i need
to morph the objects at every level to the bean i need.

Cheers
Haritha

The JSON.org page is now available in Bulgarian.

http://json.org/json-bg.html

Has any thought been given to specifying the use of HTTP/1.1 message
pipelining with JSONRequest? The current specification says:

"The browser must be able to keep open two requests per host per page.
Excess requests will be queued."

I'd rather the browser keep open one connection per host per page for
use by JSONRequest and pipeline all requests over that one connection.
In addition to making more efficient use of the network and reducing
the impact of latency, this policy would also reduce the impact of
network non-determinism on the correctness of the Javascript
application. The current specification introduces a race condition
between every pair of outstanding requests.

This kind of policy could be expressed in the API by having the client
instantiate a JSONRequest object and then send multiple requests to
the same JSONRequest object. These requests are then guaranteed to be
sent in order. Requests sent to separately instantiated JSONRequest
objects would have no order specified and could be sent over separate
connections.

Thoughts?

--Tyler

--
Use web-keys for RESTful access-control:
http://waterken.sourceforge.net/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/

Pipelining is often regarded as problematic, especially from the client side,
because of
uneven support in proxies and servers, as well as some uncomfortable decisions
you need
to make about optimisation.

Also, non-idempotent methods (e.g., POST, PUT) shouldn't be pipelined, so this
effectively
limits it to GET.

Even with pipelining on a single connection, you can't make assumptions about
messaging
ordering. Intermediaries are allowed to (and do) split requests up and put them
on
different connections, which may have different routes back to the origin.
Somewhat
pathological, but entirely possible (I've seen configurations which would allow
-- or even
encourage -- this to happen).

Cheers,

--- In json@yahoogroups.com, "Tyler Close" <tyler.close@...> wrote:
>
> Has any thought been given to specifying the use of HTTP/1.1 message
> pipelining with JSONRequest? The current specification says:
>
> "The browser must be able to keep open two requests per host per page.
> Excess requests will be queued."
>
> I'd rather the browser keep open one connection per host per page for
> use by JSONRequest and pipeline all requests over that one connection.
> In addition to making more efficient use of the network and reducing
> the impact of latency, this policy would also reduce the impact of
> network non-determinism on the correctness of the Javascript
> application. The current specification introduces a race condition
> between every pair of outstanding requests.
>
> This kind of policy could be expressed in the API by having the client
> instantiate a JSONRequest object and then send multiple requests to
> the same JSONRequest object. These requests are then guaranteed to be
> sent in order. Requests sent to separately instantiated JSONRequest
> objects would have no order specified and could be sent over separate
> connections.
>
> Thoughts?
>
> --Tyler
>
> --
> Use web-keys for RESTful access-control:
> http://waterken.sourceforge.net/
>
> Name your trusted sites to distinguish them from phishing sites.
> https://addons.mozilla.org/firefox/957/
>

Hi Mark,

Thanks for the response. I've got a few questions about your comments
and am also wondering if it's feasible to work around the issues you
raise.

On Dec 17, 2007 4:19 PM, Mark Nottingham <mnot@...> wrote:
> Pipelining is often regarded as problematic, especially from the client
> side, because of
>  uneven support in proxies and servers, as well as some uncomfortable
> decisions you need
>  to make about optimisation.

Could you elaborate on the optimization issues?

For the server support, I was figuring the Javascript code would be
signaling the server's support for message pipelining by virtue of
asking that a set of requests be sent in order. For example, if the
Javascript code sends multiple requests to the same JSONRequest
instance, it's telling the browser that the server supports HTTP/1.1
message pipelining.

>  Also, non-idempotent methods (e.g., POST, PUT) shouldn't be pipelined, so
> this effectively limits it to GET.

I remember reading something along these lines in RFC 2616, but the
argument never made any sense to me. Perhaps you could clarify the
issue. RFC 2616 contains some language about the client not knowing
what state the server is in if the connection died with multiple
outstanding POST requests, but the same is true if there is even one
outstanding POST request. Also, the situation seems to be the same if
the client is using multiple non-pipelined connections, since there
may be multiple outstanding POST requests. I expect all the POST
requests queued by the client also get sent out regardless of the
status of the previous requests, so it seems like the client is in
much the same predicament regardless of the use of pipelining.

>  Even with pipelining on a single connection, you can't make assumptions
> about messaging
>  ordering. Intermediaries are allowed to (and do) split requests up and put
> them on
>  different connections, which may have different routes back to the origin.
> Somewhat
>  pathological, but entirely possible (I've seen configurations which would
> allow -- or even
>  encourage -- this to happen).

How about this: If there is no HTTP proxy, pipeline requests;
otherwise, send the requests one at a time. So if the client asked
that requests be ordered, this is guaranteed and performance is best
effort. If the client doesn't care about ordering, but wants best
performance, then it uses separately instantiated JSONRequest objects.
Sound good?

--Tyler

--
Use web-keys for RESTful access-control:
http://waterken.sourceforge.net/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/

On 2007/12/18, at 4:53 PM, Tyler Close wrote:
> Hi Mark,
>
> Thanks for the response. I've got a few questions about your comments
> and am also wondering if it's feasible to work around the issues you
> raise.
>
> On Dec 17, 2007 4:19 PM, Mark Nottingham <mnot@...> wrote:
> > Pipelining is often regarded as problematic, especially from the
> client
> > side, because of
> > uneven support in proxies and servers, as well as some uncomfortable
> > decisions you need
> > to make about optimisation.
>
> Could you elaborate on the optimization issues?
>
There are several aspects, but if you have an outstanding request on a
connection, and another request is queued, deciding whether it's more
efficient to pipeline or to open a  new connection (or, to wait for
the other connection to clear) isn't always a simple thing to do. If
the outstanding request takes a long time to process (either because
the response is very large, or because it takes a lot of server-side
processing time), it may be better to use your other connection.

In cases where the resources on the server have low processing
overhead and are relatively homogenous in size, pipelining works well.
Subversion is a good example of this, and indeed it benefits from the
use of pipelining. I'm personally not convinced it's a great solution
when that isn't the case. YMMV.

> > Also, non-idempotent methods (e.g., POST, PUT) shouldn't be
> pipelined, so
> > this effectively limits it to GET.
>
> I remember reading something along these lines in RFC 2616, but the
> argument never made any sense to me. Perhaps you could clarify the
> issue. RFC 2616 contains some language about the client not knowing
> what state the server is in if the connection died with multiple
> outstanding POST requests, but the same is true if there is even one
> outstanding POST request. Also, the situation seems to be the same if
> the client is using multiple non-pipelined connections, since there
> may be multiple outstanding POST requests.
>
Well, it's a SHOULD NOT, not a MUST NOT, but consider a sequence of
PUT and DELETE requests; if they're pipelined and the connection drops
in the middle, the client has no idea what state the world is in; if
it doesn't pipeline, it still has to figure out whether the last
request was applied, but not the previous ones.

Also, keep in mind that connections in an intermediary aren't
necessarily "sticky" to one client; a proxy may be using one single
persistent connection to send requests from several clients to a
single server. If pipelining of nonidempotent requests were allowed
here, the failure cases get really ugly.

> I expect all the POST
> requests queued by the client also get sent out regardless of the
> status of the previous requests, so it seems like the client is in
> much the same predicament regardless of the use of pipelining.
>
Hopefully not...

> > Even with pipelining on a single connection, you can't make
> assumptions
> > about messaging
> > ordering. Intermediaries are allowed to (and do) split requests up
> and put
> > them on
> > different connections, which may have different routes back to the
> origin.
> > Somewhat
> > pathological, but entirely possible (I've seen configurations
> which would
> > allow -- or even
> > encourage -- this to happen).
>
> How about this: If there is no HTTP proxy, pipeline requests;
> otherwise, send the requests one at a time. So if the client asked
> that requests be ordered, this is guaranteed and performance is best
> effort. If the client doesn't care about ordering, but wants best
> performance, then it uses separately instantiated JSONRequest objects.
> Sound good?
>
You don't always know whether there's an intermediary there;
interception proxies (aka "transparent proxies") and HTTP accelerators
aren't apparent to the client.

--
Mark Nottingham       mnot@...