/irc-logs / w3c / #webapps / 2008-09-30 / end
Options:
- # Session Start: Tue Sep 30 00:00:00 2008
- # Session Ident: #webapps
- # [00:40] * Quits: mjs (mjs@67.170.213.205) (Quit: mjs)
- # [00:40] * Quits: heycam (cam@203.217.88.112) (Quit: bye)
- # [00:48] * Joins: mjs (mjs@67.170.213.205)
- # [01:51] * Quits: aroben (aroben@71.58.76.69) (Connection reset by peer)
- # [02:05] * Joins: heycam (cam@130.194.72.84)
- # [03:07] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [03:11] * Quits: mjs (mjs@67.170.213.205) (Quit: mjs)
- # [03:15] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
- # [03:34] * Joins: mjs (mjs@67.170.213.205)
- # [03:50] * Joins: anne (annevk@63.116.113.44)
- # [04:02] * Joins: shepazu (schepers@128.30.52.30)
- # [04:06] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
- # [04:38] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [05:11] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
- # [08:00] * Joins: heycam (cam@203.217.88.112)
- # [09:36] * Joins: arve (arve@213.236.208.22)
- # [09:36] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
- # [09:36] * Joins: arve (arve@213.236.208.22)
- # [10:03] <MikeSmith> arve: saw your mention of WebKit-based Epiphany. You know there's a quite good WebKit-based browser UI that runs on Linux now (or any Qt environment) - Arora: http://code.google.com/p/arora/
- # [10:03] <MikeSmith> very easy to build
- # [10:04] <MikeSmith> I think it's even packaged for Debian now
- # [10:04] <mjs> epiphany-webkit also runs decently
- # [10:04] <mjs> as does Midori (another Gtk/WebKit browser)
- # [10:05] <MikeSmith> last time I tried epiphany-webkit I found it unusable
- # [10:05] <MikeSmith> but I've not tried since
- # [10:06] <arve> MikeSmith: IIRC, it drags half of KDE with it
- # [10:06] <MikeSmith> *shrug*
- # [10:07] <mjs> I'm not a Linux guy, so I guess I should not really opine on these things
- # [10:07] <arve> hm, no, it didn't
- # [10:07] <arve> I'll try it
- # [10:11] <MikeSmith> arve: if you get to using it and find any bugs or have questions, there's an #arora channel on freenode.. the main developer is usually there (icefox/ Benjamin Meyer) as well as others
- # [10:12] <arve> it seems to lag behind the other two webkit browsers
- # [10:13] <arve> transformations and animations didn't work, for instance
- # [10:14] <MikeSmith> arve: that may be because that stuffs not working yet in QtWebKit .. or you may need to check out latest WebKit source and build against that
- # [10:14] <MikeSmith> http://svn.webkit.org/repository/webkit/trunk
- # [10:14] <MikeSmith> or against WebKit nightlies for Linux
- # [10:17] <mjs> Qt 4.4 is based on an older WebKit
- # [10:17] <MikeSmith> you can build against a different QtWebkit version by doing "export QT_WEBKIT=webkit_trunk" and setting WEBKITDIR, pointing to wherever you got your latest WebKit workspace/nightly checked-out/built/installed
- # [10:17] <MikeSmith> http://code.google.com/p/arora/wiki/source
- # [10:18] <MikeSmith> you can also build against Qt 4.5 snapshots if you care to
- # [10:39] <arve> marcos: why delete the preference store?
- # [10:39] <arve> let's say you have a widget implementation that doesn't implement html5 -- you're stuck without a storage API then
- # [10:47] <MikeSmith> arve: the implementation would not need to implement all of HTML5 -- just the relevant storage stuff
- # [10:48] <arve> MikeSmith: my point is that there are unwebby widget implementations as-is
- # [10:48] <arve> Yahoo widgets, for instance
- # [10:49] <MikeSmith> would the preferences-store spec be easier for those implementations to add support for than the HTML5 storage stuff would be?
- # [10:49] <MikeSmith> are those unwebby things DOM-based?
- # [10:50] <MikeSmith> the HTML5 storage spec seems not so complicated to implement (relative to others parts of the HTML5 spec at least)
- # [10:50] <arve> for someone that doesn't neccesarily implement window as the global object, yes
- # [10:51] <arve> having said that, I am not 100% sure we SHOULD cater to such implementations
- # [10:53] <MikeSmith> arve: yeah, I'd guess you'll find little disagreement in the webapps WG about that
- # [10:58] <arve> having said that, there might also be other requirements
- # [10:58] <arve> such as encrypted storage
- # [13:12] * Disconnected
- # [13:12] * Attempting to rejoin channel #webapps
- # [13:12] * Rejoined channel #webapps
- # [13:12] * Topic is 'Web Apps WG October 20-21 f2f; register @ http://www.w3.org/2002/09/wbs/35125/TPAC2008/ by October 12'
- # [13:12] * Set by ArtB on Mon Sep 29 13:29:58
- # [13:13] * Joins: timeless (timeless@65.75.195.122)
- # [13:20] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
- # [13:34] <marcos> Arve, we could build on HTML5's API. But I think we should use the same interface.
- # [13:35] <arve> marcos: I'm not sure I agree, but I can mark it as "at risk"
- # [13:36] <marcos> As MikeSmith said, the point is just to implement that one feature of HTML5. We can just lift the interface completely from HTML5 and just make sure we put a note in our spec that says that this is the same a HTML5's storage.
- # [13:37] <arve> I'm making another late-minute change, btw
- # [13:38] <arve> attribute unsigned short viewState;
- # [13:38] <arve> (hiding, fullscreen, window, "default")
- # [13:42] * Quits: mjs (mjs@67.170.213.205) (Quit: mjs)
- # [14:47] * Joins: Lachy (Lachlan@124.171.41.205)
- # [15:03] * Joins: shepazu (schepers@128.30.52.30)
- # [15:06] * Quits: Lachy (Lachlan@124.171.41.205) (Quit: This computer has gone to sleep)
- # [15:10] <marcos> Arve, I'm also becoming a bit concerned about hasFeature and if we really need it.
- # [15:30] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
- # [15:46] * Joins: aroben (aroben@71.58.76.69)
- # [15:50] * Parts: anne (annevk@63.116.113.44)
- # [15:57] <arve> marcos: elaborate?
- # [15:58] <marcos> Once an author requests a something through feature, then the API should just automatically appear bound to the appropriate object (i.e. window).
- # [15:58] <marcos> For example..
- # [15:59] <marcos> <feature id="http://a.com/camera" /> then just becomes window.camera.
- # [15:59] <arve> not neccesarily possible
- # [16:00] <arve> let me elaborate
- # [16:00] <marcos> and then, instead of hasFeature you just use if(window.camera)
- # [16:00] <arve> let's say that such a feature does not expose an interface, but instead creates a custom protocol, say p2ptv that could extend <video>
- # [16:00] <arve> it has no other interfaces, and is merely compatible with HTML5 in every way
- # [16:01] <arve> and the application wanted to use this protocol, with http as a fallback
- # [16:01] <arve> how would you do this?
- # [16:05] <marcos> if I'm understanding what you are saying correctly, you would do that with <feature id="http://p2ptv.org/someAPI">
- # [16:06] <marcos> if you wanted some kind of proprietary biding to happen to some DLL or Jar, you would need some kind of src attribute
- # [16:07] <arve> marcos: hasFeature is simply a function to check the computed value of <feature id>
- # [16:07] <arve> I still need to know whether that preference was allowed or not
- # [16:08] <marcos> you know if it is available. if (!window.camera) { ... }else{ ... i haz camera.. }
- # [16:08] <arve> if (hasFeature('p2ptv'){ url = "p2ptv://lots/of/pr0n"} else { url="http://lotsofpr0n.com/" }
- # [16:09] <arve> $('myVideoElement').src = url
- # [16:10] <arve> In the video case, I know I, theoretically, could do this in markup, using <source>
- # [16:10] <marcos> yeah, that is a good use case
- # [16:11] <arve> ... but in a scripted player, this is so much easier than always having to specify every URL
- # [16:12] <marcos> Could we still keep hasFeature, but still allow static binding on the window objects?
- # [16:12] <marcos> s/objects/object
- # [16:12] <marcos> that way, we get the best of both worlds
- # [16:13] <marcos> hasFeature becomes a convenience method that allows for checking for the availability of a precise API.
- # [16:13] <arve> I see nothing in feature/hasFeature that *prevents* it
- # [16:14] <arve> we should recommend, btw, that the feature URL is a locator, with a human-readable spec on the other end
- # [16:15] <marcos> True. The model I has proposed was a little different (it actually did prevent it). I agree.
- # [16:15] <marcos> I'll change my model to suit
- # [16:16] <marcos> So the URL locator should point to, for instance, http://www.w3.org/TR/geoloc ?
- # [16:17] <arve> for instance, yes
- # [16:17] <arve> perhaps MAY
- # [16:22] <marcos> Namespace people might not like that, but too bad :)
- # [16:23] * Joins: anne (annevk@12.198.177.3)
- # [16:24] <arve> so let's not call it a "namespace"
- # [16:25] * Quits: Dashiva (noone@80.203.127.196) (Quit: Dashiva)
- # [16:25] <marcos> I'm ok with that too.
- # [16:57] * Joins: tlr (tlr@128.30.52.30)
- # [17:26] * Parts: anne (annevk@12.198.177.3)
- # [17:31] <arve> hm, think I should probably go to http://www.w3.org/2008/security-ws/
- # [17:33] <arve> and Dominique must have the best @w3.org e-mail address possible
- # [17:50] <tlr> yes, arve, you should
- # [18:11] * Joins: Dashiva (noone@80.202.223.209)
- # [18:14] * Joins: anne (annevk@12.198.177.3)
- # [18:37] <arve> tlr: I've already hinted at chaals
- # [18:37] <tlr> excellent
- # [18:39] <arve> not that travelling suits me terribly well these days
- # [18:42] * MikeSmith is away: Less talk, more pimp walk.
- # [18:46] <ArtB> avre, marcos - Stuart Williams says someone from the TAG can meet with us in Mandelieu re widget: scheme
- # [18:46] <marcos> great
- # [18:47] <ArtB> actually he said "several members" :-)
- # [18:47] <ArtB> our agenda is http://www.w3.org/2008/webapps/wiki/WidgetsMandelieuAgenda
- # [18:47] <ArtB> s/our/our current/
- # [18:48] * marcos takes a look
- # [18:48] <ArtB> this seems like a relatively high priority for the P&C spec so I'm inclined to propose Monday
- # [18:48] <ArtB> do you have a pref, marcos or Arve?
- # [18:48] <marcos> I have no pref
- # [18:48] <marcos> Whatever is good for them
- # [18:48] <arve> no pref
- # [18:50] * Parts: anne (annevk@12.198.177.3)
- # [18:56] * ArtB wonders if Josh/timeless ever responded to Roy re widget: vs cid: (<http://www.w3.org/mid/1DC5780F-5F13-4B89-AAEA-BA1E64902056@gbiv.com>)
- # [19:39] <marcos> Hixie, when you have a minute, can you possibly give WebApps an update on the state of the DOM storage API in HTML5? is it stable(ish) or do you see it changing over the next year? It would be great if you could reply to: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0746.html
- # [19:45] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
- # [19:47] * Quits: arve (arve@213.236.208.22) (Quit: Leaving)
- # [19:55] <ArtB> marcos, why not remove the RelaxNG stuff from the spec, put it in a separate doc and then the spec would just have a link to the doc?
- # [19:56] <marcos> I think we will do that for later. For now, i want it in there so people can review it easily (As DOM did and was able to find errors)
- # [19:57] <marcos> s/DOM/Dom
- # [19:57] <marcos> hehe, get so used to typing DOM that I always do it in upper case.
- # [20:08] <ArtB> "he who does the work holds the `trump` card" :-)
- # [20:22] * Joins: anne (annevk@12.198.177.3)
- # [20:30] * Quits: tlr (tlr@128.30.52.30) (Ping timeout)
- # [21:00] <marcos> or "it's my party and I'll cry if I want to"?
- # [21:06] * marcos is sorry if that song is now continuously playing back in anyone's head!
- # [21:47] * Parts: anne (annevk@12.198.177.3)
- # [21:54] <Hixie> marcos: you can see the stability of any part of the html5 spec by looking at the annotations in the margins of the spec
- # [22:13] * Quits: ArtB (ce846302@128.30.52.43) (Quit: CGI:IRC)
- # [22:32] * Joins: anne (annevk@63.116.113.44)
- # [22:37] * Joins: arve (arve@80.202.65.163)
- # [22:48] <marcos> hixie, thanks.
- # [23:32] * Quits: arve (arve@80.202.65.163) (Quit: Leaving)
- # Session Close: Wed Oct 01 00:00:00 2008
The end :)