Dear WHATWG,
I would like to revisit HTML5 section 4.10.4.3, as circumstances have
changed since it was last discussed. For those of you not familiar
with the issue, section 4.10.4.3 defines the value property of input
type=file/ elements. This behavior is not currently consistent
across all
On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 27 Aug 2009, Michael A. Puls II wrote:
Here's an example that uses a more modern plug-in that shows what
browsers do.
window.onload = function() {
var obj = document.createElement(object);
obj.type =
Alex Henrie writes:
A better solution exists: drop the fakepath requirement. Browsers that
desire extra compatibility can add fakepath to their compatibility
modes as they choose.
Browsers have 'extra' compatibility is one of the things which currently
causes the _most_ grief for many web
Ian Hickson wrote:
On Fri, 28 Aug 2009, Mike Wilson wrote:
My chain of thoughts is something like below (this is just
a general
picture so don't take it too literally):
- invent a more restrictive mechanism for script access
between documents from the same origin (host) so it
Am Donnerstag, den 03.09.2009, 08:29 +0100 schrieb Smylers:
Like other compatibility mode behavior, implementation would be
voluntary and not governed by the W3C.
What other compatibility mode behavior?
Maybe he is alluding to the IE local zone ?
--
Nils Dagsson Moskopp
On Thu, Sep 3, 2009 at 12:54 AM, Aryeh Gregorsimetrical+...@gmail.com wrote:
In 4.10.10:
The purposes of this requirement, lines are delimited by the start of
the string, the end of the string, and U+000D CARRIAGE RETURN - U+000A
LINE FEED (CRLF) character pairs.
I can't parse this
On Sep 3, 2009, at 00:39, Ian Hickson wrote:
2. Its element must not be set to display of 'none' (and therefore
must
not be part of fallback content that's not triggered yet).
This is definitely a bug; the fallback handling is done in a
different way
in HTML5, anyway.
Why is this a
On Sun, 30 Aug 2009, Michael Nordman wrote:
These arguments against the proposal are not persuasive. I remain of the
opinion that the GlobalScript proposal has merit.
That's possible; I would recommend taking up a Global Script proposal in
the public-webapps working group, though, as it is
On Sun, 30 Aug 2009, Jeremy Keith wrote:
I'm finding the wording of the note on the content between opening and closing
audio and video tags to be a tad confusing. It reads:
In particular, this content is not fallback content intended to address
accessibility concerns.
This could be
On Sun, 30 Aug 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
On Sun, 2 Sep 2007, Gavin Sharp wrote:
It appears this behavior was explicitly chosen in Mozilla, in bug 190561
(https://bugzilla.mozilla.org/show_bug.cgi?id=190561). I think the
arguments given in that bug might merit
On Mon, 31 Aug 2009, Jonas Sicking wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
'yield' usually refers to halting execution. I would expect the above
name to stop the current thread and allow other threads to run. While
that is what
On Mon, 31 Aug 2009, Philip J�genstedt wrote:
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip J�genstedt wrote:
As far as I can see there's no good reason why createImageData
should take a float as input rather than unsigned long.
On Mon, 31 Aug 2009, Mike Wilson wrote:
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
I'm currently wrapping my head around the notion of
first script in the spec [1]. It's description is
a bit terse and the subject seems non-trivial, so
maybe the text could be
On Thu, 03 Sep 2009 13:54:03 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 31 Aug 2009, Philip J�genstedt wrote:
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip J�genstedt wrote:
As far as I can see there's no good reason why
On Wed, 02 Sep 2009 15:38:00 +0600, ~:'' ありがとうございました
j.chetw...@btinternet.com wrote:
Chaals,
thanks for yet another well considered and easy-to-read response*!
your comments around ARIA and SVG are noted.
however you fail to address the central issue, which as Filipe Sanches
wrote me in
On Wed, 02 Sep 2009 22:26:53 +0200, Dirk Pranke dpra...@chromium.org
wrote:
1) ...
I'll let someone else address this one.
2) wrap=off does not appear to be a legitimate value, despite being
implemented in all the major browsers. Is this an oversight, or an
intentional omission?
It is
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
Maintaining the user's expectations of privacy is critical.
The fact
Philip Jägenstedt wrote:
I wasn't involved then, but I can only presume that there was no
perceived benefit of high-DPI ImageData since you can get high-quality
rendering just as well with techniques that don't rely on the canvas
being higher resolution than the display device.
To be clear,
Hixie wrote:
Fixed.
Thanks. Much appreciated.
Don't forget to update the note for audio as well as video.
Also, with the new wording of the note removing the link to the
section on fallback content, it might be a good idea to update the
opening of the preceding paragraph from:
Content
On Thu, Sep 3, 2009 at 2:44 AM, Mike Wilsonmike...@hotmail.com wrote:
Ok, that sort of defeats the point as it will not be possible
to depend on this security function for HTML5 features released
before its appearance in the standard - my idea was that f ex
WebStorage would refer to (and
Ian Hickson wrote:
On Mon, 31 Aug 2009, Mike Wilson wrote:
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
[...]
Imagine that I want my loaded page:
/pages/section1/thing1
be able to impersonate:
/pages/section2/thing2
how do you envision
On Thu, Sep 3, 2009 at 7:56 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
Adam Barth wrote:
On Thu, Sep 3, 2009 at 2:44 AM, Mike Wilson wrote:
Ok, that sort of defeats the point as it will not be possible
to depend on this security function for HTML5 features released
before its appearance in the standard - my idea was that f ex
WebStorage would refer to (and
On Thu, Sep 3, 2009 at 8:56 AM, Ian Hicksoni...@hixie.ch wrote:
The fact that local storage can be used for cookie resurrection means we
have to make sure that clearing one clears the other. Anything else would
be a huge privacy issue (just as Flash has been).
The *only* reason Flash is a
On Thu, Sep 3, 2009 at 7:30 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Mike Shaver wrote:
The multiple server-side processes that end up involved over the course
of the user's interaction do need to share state with each other, and
preserving blocking semantics for accessing
On Thu, Sep 3, 2009 at 1:29 AM, Smylerssmyl...@stripey.com wrote:
Like other compatibility mode behavior, implementation would be
voluntary and not governed by the W3C.
What other compatibility mode behavior?
IE has a huge Compatibility View and lots of additional settings
available. Firefox
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's implementation has always worked with high dpi backing stores
and follows the spec accordingly.
--Oliver
I'm finding it hard to envision the kind of applications that are going to
be created that will need to take advantage of multiple cores when there are
orders of magnitude more cores than applications. Do you believe that
we're going to see a fundamental shift in the kinds of things people are
On Thu, Sep 3, 2009 at 12:23 PM, Alex Henriealexhenri...@gmail.com wrote:
Yes, we need a standard. Currently there are two competing behaviors,
each backed by multiple major browser vendors. Ian wants to
standardize on the stupider behavior and expects the remaining browsers
to implement it.
On Thu, Sep 3, 2009 at 10:35 AM, Aryeh Gregorsimetrical+...@gmail.com wrote:
Why is that expectation any more problematic than expecting IE and
Opera to change? How reluctant are each of the major vendors to
change their behavior?
If the cost of changing the browsers is equal, why pick the
On Tue, Aug 25, 2009 at 4:24 PM, Aryeh Gregorsimetrical+...@gmail.com wrote:
For that matter, it might be nice if some patterns just refused to let
you enter anything that doesn't meet the pattern -- but not all,
clearly. E.g., [ -~]* to restrict to ASCII would really like to
just not let you
On Wed, Aug 26, 2009 at 10:18 AM, Max Romantschukm...@romantschuk.fi wrote:
I think it's important not to forget that a great deal of web applications
are internal applications not exposed to the Internet. In an environment
like that performance issues with evaluating regexps against a large
On Thu, Sep 3, 2009 at 8:07 PM, timelesstimel...@gmail.com wrote:
Si no halas ustedes Español podria visitar al: http://translate.google.com/t
How embarrassing, I fixed the typo elsewhere:
Si no hablas ustedes Español podria visitar al: http://translate.google.com/t
On Thu, Sep 3, 2009 at 9:29 AM, Smylerssmyl...@stripey.com wrote:
If one major browser implements non-standard behaviour for compatibility
with existing content, it would have an advantage with users over other
browsers -- those other browsers would likely want to implement it, to
avoid losing
On Sun, Aug 30, 2009 at 4:06 AM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
If getStorageUpdates() actually returned how *many* updates there
were, it could be a vaguely useful name.
If the answer is 0, then my
On Thu, Sep 3, 2009 at 1:05 PM, Alex Henriealexhenri...@gmail.com wrote:
If the cost of changing the browsers is equal
Is it? What do the implementors on each side think? Just because the
same number of lines would have to be changed doesn't mean the cost is
equal, in terms of getting people
I think the canonical racy case is the page wants to keep a counter for the
number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to achieve this without the mutex - the
proposal below would break down if two pages tried to increment the cookie
value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/1/09 7:31 PM, Jeremy Orlow wrote:
Does the silence mean that no one has any intention of implementing
this? If so, maybe we should resign ourselves to a break in the single
threaded illusion for cookies. This doesn't seem too outlandish
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
Is it important that continue to work without racing? I don't think it's
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedbergbenja...@smedbergs.us wrote:
* When the script sets document.cookie, it calculates the delta with the
original data and commit the changes.
What if there's a conflict with other changes that happened in the meantime?
On Thu, 3 Sep 2009, Mike Wilson wrote:
- calling pushState(..., /pages/section1/thing2) when
first script's basedir=/pages/section1 will be ok
- calling pushState(..., /pages/section2/thing2) when
first script's basedir=/pages/section1 will not be
allowed (and throw).
Is any of
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg bsmedb...@mozilla.comwrote:
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to
On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
On Thu, Sep 3, 2009 at 7:56 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose
On Thu, Sep 3, 2009 at 6:49 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You could just *not* specify that LocalStorage is worthless for
anything but a cache.
This seems like a severe overstatement given the current spec. It's not
worthless. It won't be guaranteed to be thrown away all
On Thu, 03 Sep 2009 18:23:37 +0200, Alex Henrie alexhenri...@gmail.com
wrote:
On Thu, Sep 3, 2009 at 1:29 AM, Smylerssmyl...@stripey.com wrote:
Like other compatibility mode behavior, implementation would be
voluntary and not governed by the W3C.
What other compatibility mode behavior?
On Thu, Sep 3, 2009 at 5:33 PM, Ian Hicksoni...@hixie.ch wrote:
On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
On Thu, Sep 3, 2009 at 7:56 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and
Ian Hickson wrote:
On Thu, 3 Sep 2009, Mike Wilson wrote:
- calling pushState(..., /pages/section1/thing2) when
first script's basedir=/pages/section1 will be ok
- calling pushState(..., /pages/section2/thing2) when
first script's basedir=/pages/section1 will not be
allowed
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And more-than-a-cache-Storage can be explicitly turned off or have its
quota dropped to zero. If that's important, the browsers will make it
easy. And more importantly, they'll make it *consistent* (within the
On Thu, Sep 3, 2009 at 5:48 PM, Peter Kastingpkast...@google.com wrote:
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And more-than-a-cache-Storage can be explicitly turned off or have its
quota dropped to zero. If that's important, the browsers will make it
On Fri, 4 Sep 2009, Mike Wilson wrote:
Let's say that I have rights to post to a blog on:
www.corporatesite.com/fan/blog
Assuming I can get some JavaScript inside one of my blog
posts, I can then pretend I am redirecting the user to:
www.corporatesite.com/topclientsonly/login
while I
Mike Wilson wrote:
The result is that the address bar URL can't be trusted, as
any page on the site can impersonate any other without
consent from that page or part of the site?
Someone will correct me if I'm wrong, but I think this is already
pretty much the case with today's same-origin
On Thu, Sep 3, 2009 at 3:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Again, this is precisely what we as UA authors can do now, with the
current
spec. I'm not sure what you're arguing. Our job is to make sure users
whose philosophy is like Ian's are as well-served as users whose
On Thu, Sep 3, 2009 at 5:59 PM, Peter Kastingpkast...@google.com wrote:
On Thu, Sep 3, 2009 at 3:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You may have missed the part where Ian said that, to protect their
user's privacy, browsers *must* clear cookies and LocalStorage at the
same time.
On Fri, Sep 4, 2009 at 12:33 AM, Ian Hicksoni...@hixie.ch wrote:
Flash's privacy problem can be removed by uninstalling Flash. They're not
a license to add more privacy problems to the platform.
And a permanent's storage potential privacy problems could also be
removed by having separate Delete
On Thu, Sep 3, 2009 at 4:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
10 hours ago, Hixie said:
The fact that local storage can be used for cookie resurrection means we
have to make sure that clearing one clears the other. Anything else would
be a huge privacy issue (just as Flash has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/3/09 5:06 PM, Aryeh Gregor wrote:
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedbergbenja...@smedbergs.us
wrote:
* When the script sets document.cookie, it calculates the delta with the
original data and commit the changes.
What if there's
On Mon, 22 Dec 2008, Shital Shah wrote:
I'm wondering if there are any ideas being discussed to add an ability
so users can embed images in editable areas.
Many modern web applications including blogs and wikis allow users to
visually edit content with rich formatting. However present
On Fri, 4 Sep 2009, Eduard Pascual wrote:
Now, this question is mostly addressed to Ian, as the only one who can
provide a 100% accurate answer: based on the spec text intent, would the
idea of having separate Delete cookies and Delete everything buttons
side by side be conformant?
Yes.
On Thu, Sep 3, 2009 at 7:12 PM, Eduard Pascualherenva...@gmail.com wrote:
The problem is not what the spec says, or is supposed to say, but how
does it say it. This long discussion seems to be mostly around the
point that the current wording is too likely to be miss-interpreted as
The delete
On Thu, 3 Sep 2009, Aryeh Gregor wrote:
I think this is too specific -- it should say something more like User
agents should make it clear to the user that to ensure privacy from
sites, he must delete persistent storage as well as HTTP session
cookies. But the current wording doesn't
On Thu, Sep 3, 2009 at 7:26 PM, Ian Hicksoni...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
Not really. You still have the sentence User agents should present
the persistent storage feature to the
On Thu, 2 Jul 2009, Ryosuke Niwa wrote:
Hi, I just realized that in HTML4.01 spec, DTD doesn't seem to allow
nested OL or UL without LI. See
http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.2 In fact, the
nested list example is marked deprecated. �But in practice, all major
user
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section actually muddies the waters.
Something like this would be more clear: If
On Fri, Sep 4, 2009 at 1:23 AM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 4 Sep 2009, Eduard Pascual wrote:
If it would (and a lot of people here seem to be arguing that it would),
then this discussion could be easily be put to an end by tweaking the
wording in a way that makes this more
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's implementation has always worked with high dpi backing
On Thu, Sep 3, 2009 at 6:31 PM, Peter Kastingpkast...@google.com wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section
I don't see what the problem here is. How is it wrong? Why can't a list be a
type of list item?
Focusing more on practicalities, every browser produces and deals correctly
with this type of HTML. Given that contentEditable is used by just about
every rich-text email or blog-posting service, it's
On Thu, 3 Sep 2009, Ojan Vafai wrote:
I don't see what the problem here is. How is it wrong? Why can't a list be a
type of list item?
It can:
ol
li
ol.../ol
/li
/ol
The request was for ol to be directly inside ol, which makes no sense.
Focusing more on practicalities,
On Thu, 3 Sep 2009, Aryeh Gregor wrote:
On Thu, Sep 3, 2009 at 7:26 PM, Ian Hicksoni...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
Not really. You still have the sentence User agents should
On Thu, 3 Sep 2009, Peter Kasting wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section actually muddies the waters.
On Thu, Sep 3, 2009 at 4:33 PM, Ian Hickson i...@hixie.ch wrote:
I don't think nested lists really make much sense -- a list is a list of
items, and a nested list is just one of the items.
Are you arguing that all major implementations are wrong, and that we need
to fix them? Even though
On Thu, 3 Sep 2009, Ryosuke Niwa wrote:
On Thu, Sep 3, 2009 at 4:33 PM, Ian Hickson i...@hixie.ch wrote:
I don't think nested lists really make much sense -- a list is a list
of items, and a nested list is just one of the items.
Are you arguing that all major implementations are wrong,
On Thu, Sep 3, 2009 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 3 Sep 2009, Peter Kasting wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which
gives
more background. Does that satisfy your
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's
On Aug 30, 2009, at 7:46 PM, Ian Hickson wrote:
On Sat, 22 Aug 2009, Francisco Tolmasky wrote:
Thanks.
The big thing to realise about this API is that it isn't young -- it's
what IE has shipped for about 10 years, and what Safari has had for
a bit
less than that.
We should definitely
On Fri, Sep 4, 2009 at 8:17 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
What kind of conflict? There is no need to merge individual cookies:
whichever one was set (or removed) last wins.
I think this strategy would work fine for cookies since the HTTP side of
them is inherently racy. I
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
I do agree with Jeremy that we should rethink the spec language around
cookie consistency to reflect what
On Fri, Sep 4, 2009 at 10:25 AM, Drew Wilson atwil...@google.com wrote:
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
And to be clear: I don't have
On Fri, Sep 4, 2009 at 2:24 AM, timeless timel...@gmail.com wrote:
On Sun, Aug 30, 2009 at 4:06 AM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
If getStorageUpdates() actually returned how *many* updates there
On Thu, 13 Aug 2009, Alexey Proskuryakov wrote:
13.08.2009, в 4:42, Ian Hickson написал(а):
A note explaining that the close event will be dispatched at
server's discretion (or on subsequent connection timeout),
potentially long time after close() is called, would likely make the
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers to
use the more difficult database api for all storage needs, and to roll their
own change event mechanisms (based on postMessage). Thats a bunch of busy
work if a name/value pair
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult database api for all storage needs, and to roll
their own change event
On Fri, Sep 4, 2009 at 10:59 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult
On Fri, 14 Aug 2009, Jeremy Orlow wrote:
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 7 Aug 2009, Jonas Sicking wrote:
I agree that these are very interesting features. Especially
connection multiplexing is something that I think is a good idea,
for
On Fri, 14 Aug 2009, Jonas Sicking wrote:
How do you envisage multiplexing working? It's not clear to me what we
could do that would be easier to handle than just having the script
manually do the multiplexing at the application layer. What would the
API look like? What would the wire
85 matches
Mail list logo
