Re: [whatwg] createObjectURL(stream) protocol issue

[Darin Fisher]

Putting implementation details aside, I agree that it is a bit unfortunate
to refer to a stream as a blob.  So far, blobs have always referred to
static, fixed-size things.

This function was originally named createBlobURL, but it was renamed
createObjectURL precisely because we imagined it being useful to pass things
that were not blobs to it.  It seems reasonable that passing a Foo object to
createObjectURL might mint a different URL type than what we would mint for
a Bar object.

It could also be the case that using blob: for referring to Blobs was
unfortunate.  Maybe we do not really need separate URL schemes for static,
fixed size things and streams.

Hmm...
-Darin



On Thu, Aug 11, 2011 at 2:13 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <
tom...@google.com> wrote:

> Would it be possible to give the associated URL for a mediastream to have
> its own protocol, for example mediastream:, instead of the proposed blob:?
>
> window . URL . createObjectURL(stream)
> Mints a Blob URL to refer to the given MediaStream.
>
>
> This would tremendously help the implementation.
>
> Thanks in advance,
> Tommy
>
>
> --
> Tommy Widenflycht, Senior Software Engineer
> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
> Org. nr. 556656-6880
> And yes, I have to include the above in every outgoing email according to
> EU
> law.
>

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ryosuke Niwa]

On Fri, Aug 12, 2011 at 3:11 PM, Ehsan Akhgari  wrote:

> On 11-08-12 6:10 PM, Ryosuke Niwa wrote:
>>
>> But having authors add flag in almost all cases isn't that nice either.
>>
>
> Why do you think that authors need to specify the flag in almost all cases?
>

Because almost all text editing operations need to restore selection upon
redo.

- Ryosuke

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ehsan Akhgari]

On 11-08-12 6:10 PM, Ryosuke Niwa wrote:

On Fri, Aug 12, 2011 at 3:07 PM, Ehsan Akhgari  wrote:


On 11-08-09 6:36 PM, Jonas Sicking wrote:


Sure, your API is more convenient in certain situations. But it also
encourages code duplication (I'll note that in the examples you
originally provided in this thread you always ended up duplicating
code between apply/reapply), which easily leads to bugs.



I think this is a very important point, and this downside makes me think
that we shouldn't expose a reapply API.  Since almost every case that I can
think of where having a reapply function would make more sense requires
authors to maintain other state information in their transaction objects, I
don't think that maintaining one more boolean flag is going to make things
noticeably harder for them.



But having authors add flag in almost all cases isn't that nice either.


Why do you think that authors need to specify the flag in almost all cases?

Ehsan

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ryosuke Niwa]

On Fri, Aug 12, 2011 at 3:07 PM, Ehsan Akhgari  wrote:

> On 11-08-09 6:36 PM, Jonas Sicking wrote:
>>
>> Sure, your API is more convenient in certain situations. But it also
>> encourages code duplication (I'll note that in the examples you
>> originally provided in this thread you always ended up duplicating
>> code between apply/reapply), which easily leads to bugs.
>>
>
> I think this is a very important point, and this downside makes me think
> that we shouldn't expose a reapply API.  Since almost every case that I can
> think of where having a reapply function would make more sense requires
> authors to maintain other state information in their transaction objects, I
> don't think that maintaining one more boolean flag is going to make things
> noticeably harder for them.
>

But having authors add flag in almost all cases isn't that nice either.

- Ryosuke

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ehsan Akhgari]

On 11-08-09 6:36 PM, Jonas Sicking wrote:

On Tue, Aug 9, 2011 at 3:11 PM, Ryosuke Niwa  wrote:

On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking  wrote:

I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with either API.


Right, they're isomorphic.


It's just a matter of which pattern is more common and so which one we
should make more convenient. If almost everyone puts the same code in apply
and reapply then we're just creating more work for people.

Here's how you'd implement the apply/reapply/unapply syntax using simply
apply/unapply

apply: function() { if (!this.applied) { action1(); this.applied = true; }
else { action2(); }
unapply: unapply


One thing I don't like about this approach is that it requires a flag.  With
my proposal, all you need to do is to call a function. Also, we can make it
so that when you don't supply a value to reapply (i.e. reapply is null),
then undoManager automatically calls apply instead (I always intended this
behavior from the beginning but I've apparently left this details out).


Sure, your API is more convenient in certain situations. But it also
encourages code duplication (I'll note that in the examples you
originally provided in this thread you always ended up duplicating
code between apply/reapply), which easily leads to bugs.


I think this is a very important point, and this downside makes me think 
that we shouldn't expose a reapply API.  Since almost every case that I 
can think of where having a reapply function would make more sense 
requires authors to maintain other state information in their 
transaction objects, I don't think that maintaining one more boolean 
flag is going to make things noticeably harder for them.


Ehsan

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

[Ehsan Akhgari]

On 11-08-11 6:07 PM, Jonas Sicking wrote:

On Thu, Aug 11, 2011 at 2:56 PM, Ryosuke Niwa  wrote:

On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgari  wrote:


I think the confusion is arising because you chose to attach undoManager
to elements, not nodes.  Note that document _is_ a node in the DOM, but it's
not an element.  I think we should just modify the spec to attach
undoManager to nodes.  Once we have that, we don't need to treat
documentElement specially at all, it just looks at its parent (the document
node) and gets the undoManager from there.


Makes sense.


The only downside is that we should explicitly prohibit some node types
from having an undoManager where it doesn't make sense (such as text nodes,
comment nodes, etc.).  We can enumerate them explicitly and say that
accessing the undoManager on these types of nodes will throw.


Alternatively, can we say that only Element and Document are allowed to have
it?


Yup, that's what I think we should do. Though it'll sort of fall out
naturally since UndoManagers are by default only available on
Documents, and the only way you can enable it on other Nodes is
through attributes, which only exist on Elements.


Yes, that sounds good to me too.

Ehsan

Re: [whatwg] createObjectURL(stream) protocol issue

[Ian Hickson]

On Fri, 12 Aug 2011, Tommy Widenflycht (�~[~O�~Z��~[~X�~[~X�~Z�) wrote:
>
> Imho conceptually streamed media is not the same as data from a file and 
> thus should be separated. Specifically the code for the video tag for 
> example now has to ask around what this URL actually points to before 
> taking action.

How do you do it for http:, where the URL doesn't distinguish the two 
cases?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement

[Aaron Colwell]

Hi Mark,

comments inline...

On Thu, Aug 11, 2011 at 9:46 AM, Mark Watson  wrote:

> I think it would be good if the API recognized the fact that the media data
> may becoming from several different original files/streams (e.g. different
> bitrates) as the player adapts to network or other conditions.
>

I agree. I intend to document this when I spec out the format of the byte
stream that is passed into this API. Initially I'm focusing on WebM which
requires this type of functionality if the Vorbis initialization data ever
needs to change during playback. My intuition says that Ogg & MP4 will
require similar solutions.


>
> The different files may have different initialization information (Info and
> Tracks in WebM, Movie Box in mp4 etc.), which could be provided either in
> the first append call for each stream or with a separate API call. But
> subsequently you need to know which initialization information is relevant
> for each appended block. An integer streamId in the append call would be
> sufficient - the absolute value has no meaning - it would just associate
> data from the same stream across calls.
>

Since I'm using WebM for the byte stream I don't need to add explicit
streamIds to the API or data. StreamIDs are already in the byte stream. Ogg
bitstream serial numbers, and MP4 track numbers should serve the same
purpose.


>
> The alternatives are:
> (a) to require that all streams have the same or compatible initialization
> information or
> (b) to pass the initialization information every time you change streams
>
> (a) has the disadvantage of constraining encoding, and making adding new
> streams more dependent on the details of how the existing streams were
> encoded/packaged
> (b) is ok, except that it is nice for the player to know "this data is from
> the same stream you were playing a while ago" - it can re-use some
> previously established state - rather than every stream change being 'out of
> the blue'.
>

I'm leaning toward (b) right now. Any time a change in stream parameters is
needed new INFO & TRACKS elements will be appended before the media data
from the new source. This is similar to how Ogg chaining works. I don't
think we need unique IDs for marking this state. The media engine can look
at the new codec config data and see if it matches anything it has seen
before. If so then it can simply reuse whatever resources it see fit.
Another thing to note is that just because we append this data every time a
stream switch occurs, it doesn't mean we have to transfer that data across
the network each time. JavaScript can cache this data and simply append it
when necessary.


>
> A separate comment is that practically we have found it very useful for the
> media player to know the maximum resolution, frame rate and codec
> level/profile that will be used, which may be different from the resolution
> and codec/level/profile of the first stream.
>
>
I agree that this info is useful, but it isn't clear to me that this API
needs to support that. Existing APIs like
canPlayType()
could
be used to determine whether specific codec parameters are supported. Other
DOM APIs could be used to determine max screen size. This could all be used
to prune the candidate streams sent to the MediaSource API.


Aaron

[whatwg] Component Model Progress

[Joel Laird]

Hi,

I have been following the w3c discussion at
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1345.html and
have read the use cases at
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases.
I think such as feature is very useful as web applications become more
prevalent and especially with the interest in web operating systems. The
available JavaScript GUI frameworks are great, but we need some
standardisation and simplification to promote growth in this area.

I would like to get involved and was wondering what the current status is of
this feature?

For my part, as a hobbyist web developer, I have suggestions as to how I'd
like to use this feature and have written a framework (
http://code.google.com/p/htmlcomponentframework/) and an article (
http://www.codeproject.com/KB/HTML/htmlcomponentframework.aspx)
of how the functionality could be exposed.
With time I would like to improve this and have something similar integrated
within the browser; for now it depends on div and iframe elements whereas
ideally I'd like to be able to define new elements and use them within the
HTML body. The usage, though, is essentially the same:

Within the parent (hosting) page:

   - Add elements to the HTML head to define the components that are to be
   used.
   - Add elements to the HTML body (either by markup or DOM manipulation)
   where the components are to be shown.
   - Integrate code with the components by: registering event handlers with
   them, firing events at them, and altering their exposed DOM.

To create a component:

   - Write a normal HTML+CSS+JavaScript web page to implement the desired
   functionality.
   - Add elements to the HTML head to define: the component's exposed DOM,
   the events it can receive, the events it can raise.


The implications of something like this reach further than just simplifying
the modularisation of web applications. For example, it would be possible
to:

   1. Define an address book component's contract.
   2. Expose a component fulfilling the contract from online address book
   applications.
   3. Consume my preferred address book application provider from within an
   online email client or social network site by pointing them at the
   component's URL and using oAuth to authorise access.
   4. From within the consuming web application select and edit my contacts
   using my actual address book application provider that I am familiar with.


Regards,
Joel

Re: [whatwg] createObjectURL(stream) protocol issue

[ᛏᚮᛘᛘᚤ]

Imho conceptually streamed media is not the same as data from a file and
thus should be separated. Specifically the code for the video tag for
example now has to ask around what this URL actually points to before taking
action.

/Tommy

On Thu, Aug 11, 2011 at 22:08, Ian Hickson  wrote:

> On Thu, 11 Aug 2011, Tommy Widenflycht (á~[~Oá~Z®á~[~Xá~[~Xá~Z¤) wrote:
> >
> > Would it be possible to give the associated URL for a mediastream to
> > have its own protocol, for example mediastream:, instead of the proposed
> > blob:?
> >
> > window . URL . createObjectURL(stream)
> > Mints a Blob URL to refer to the given MediaStream.
> >
> > This would tremendously help the implementation.
>
> Could you elaborate? In what sense does it impact the implementation?
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'




-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU
law.