fluid-work IRC Logs-2009-06-11

[08:10:43 EDT(-0400)] * laurel (n=laurel@dsl-207-112-65-132.tor.primus.ca) has joined #fluid-work
[08:15:40 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:21:33 EDT(-0400)] * laurel (n=laurel@dsl-207-112-65-132.tor.primus.ca) has left #fluid-work
[08:30:48 EDT(-0400)] * jsilvaa (n=jsilva@CABLE-72-53-95-24.cia.com) has joined #fluid-work
[08:58:44 EDT(-0400)] * laurel (n=laurel@dsl-207-112-65-132.tor.primus.ca) has joined #fluid-work
[09:18:25 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[09:28:31 EDT(-0400)] * hydee (i=heidi@142.150.154.170) has joined #fluid-work
[09:47:02 EDT(-0400)] * mackrauss (n=armin@142.150.154.129) has joined #fluid-work
[09:47:10 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[09:56:52 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[09:58:52 EDT(-0400)] * anastasiac (n=team@142.150.154.189) has joined #fluid-work
[10:17:55 EDT(-0400)] <clown> anastasiac, justin_o, a followup on our brief discussion of alt text the other day:
[10:18:06 EDT(-0400)] <clown> A W3C task force have published a set of recommendations.
[10:18:19 EDT(-0400)] <clown> not sure if they are public, but here's the url:
[10:18:51 EDT(-0400)] <clown> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
[10:19:12 EDT(-0400)] <clown> the handling of the "upload to photo site" is the use case at the end of the document.
[10:21:10 EDT(-0400)] <anastasiac> clown - thanks!
[10:22:39 EDT(-0400)] <clown> anastasiac: you're welcome. I'd have included jacob, but he doesn't seem to be here (he seemed interested the other day).
[10:27:02 EDT(-0400)] <clown> Justin_o: a question, if you are free.
[10:27:09 EDT(-0400)] <Justin_o> clown: sure
[10:27:43 EDT(-0400)] <clown> do you or Jacob or anyone css-aware know how good the advice is on the #css channel (on freenode)?
[10:28:50 EDT(-0400)] <Justin_o> clown: hmm... i don't know... i tend to just ask jacob all my questions .. I'll see if i can ask him about it for you though
[10:29:07 EDT(-0400)] <clown> cool, thanks Justin_o
[10:29:35 EDT(-0400)] <Justin_o> clown: he hasn't been there before
[10:30:29 EDT(-0400)] <clown> Justin_o: okay, good to know.
[10:35:20 EDT(-0400)] <clown> Justin_o: related question – do you or Jacob (or anyone else) know of a good IRC css "help" channel?
[10:35:58 EDT(-0400)] * clown noting that the answer can be "no".
[10:36:31 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[10:36:53 EDT(-0400)] <Justin_o> clown: I think the best place to ask will be here to fj4000 or hiedi
[10:37:10 EDT(-0400)] <Justin_o> clown: fj4000 was saying that you he usually checks out websites for into
[10:37:24 EDT(-0400)] <clown> my that was garbled...
[10:39:03 EDT(-0400)] * fj4000 and Heidi have merged for today into a single CSS blob
[10:40:33 EDT(-0400)] * clown wonders if the fj4000Heidi blob is renderable in any browser.
[10:40:41 EDT(-0400)] * clown groans.
[10:40:46 EDT(-0400)] * clown at himself
[10:56:39 EDT(-0400)] <fj4000> we are renderable in everything and anything
[10:56:45 EDT(-0400)] <fj4000> including lynx
[10:56:49 EDT(-0400)] * athena giggles
[10:57:03 EDT(-0400)] <athena> you become ascii animations?
[10:57:31 EDT(-0400)] <athena> like the telnet starwars?
[10:58:39 EDT(-0400)] <fj4000> .88888888:. 88888888.88888. .8888888888888888. 888888888888888888 88' `88' `88888 88 88 88 88 88888 88_88_::88:88888 88:::,::,:::::8888 88`:::::::::'`8888 .88 `::::' 8:88. 8888 `8:888. .8888' `888888. .8888:.. .::. ...:'8888888:. .8888
[10:58:46 EDT(-0400)] <fj4000> oh noz!
[10:58:50 EDT(-0400)] <athena> uhoh!
[10:58:50 EDT(-0400)] <fj4000> i broke
[10:58:52 EDT(-0400)] <clown> nic try...
[10:58:58 EDT(-0400)] <clown> s/nic/nice
[10:59:04 EDT(-0400)] * athena offers fj4000 some tasty linebreaks
[10:59:31 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[10:59:34 EDT(-0400)] <clown> fj4000, I used Palatino for my display – do I need to switch to mono font?
[10:59:35 EDT(-0400)] * fj4000 cough, choke
[10:59:40 EDT(-0400)] <jamon> http://www.network-science.de/ascii/ is my favourite ascii generator
[11:15:26 EDT(-0400)] <athena> so what exactly is going to be included in this new mobile FSS project?
[11:15:45 EDT(-0400)] <athena> is it going to be sort of like the regular FSS, but geared towards mobile devices?
[11:15:51 EDT(-0400)] <athena> or will it be more than that?
[11:34:31 EDT(-0400)] * hydee (i=heidi@142.150.154.170) has joined #fluid-work
[11:55:15 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined #fluid-work
[12:12:08 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[12:20:17 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[12:30:25 EDT(-0400)] * clown_afk (n=clown@142.150.154.101) has joined #fluid-work
[12:34:31 EDT(-0400)] * colinclark (n=colin@192.42.249.7) has joined #fluid-work
[12:55:21 EDT(-0400)] * mackrauss (n=armin@142.150.154.129) has joined #fluid-work
[12:59:39 EDT(-0400)] * laurel (n=laurel@dsl-207-112-65-132.tor.primus.ca) has joined #fluid-work
[13:13:53 EDT(-0400)] * colinclark (n=colin@192.42.249.7) has joined #fluid-work
[13:22:54 EDT(-0400)] <colinclark> Hey hydee and fj4000.
[13:23:13 EDT(-0400)] <hydee> heyoo
[13:24:48 EDT(-0400)] <colinclark> Couple of updates on issue of iPhone styling and graphics.
[13:25:23 EDT(-0400)] * hydee is listening
[13:25:33 EDT(-0400)] <colinclark> People here are generally sort of confused about the whole thing, but I have managed to get some substance in the end.
[13:25:59 EDT(-0400)] <colinclark> So, my general sense is that most of the earlier CSS frameworks for the iPhone have been too graphics-heavy.
[13:26:13 EDT(-0400)] <colinclark> You've probably already taken a look at the various Safari Dev Centre links I posted.
[13:26:14 EDT(-0400)] <hydee> has that been a limitation to ppl?
[13:26:34 EDT(-0400)] <colinclark> There are clearly ways to style most iPhone idioms.
[13:26:37 EDT(-0400)] * fj4000 sorry about that
[13:26:41 EDT(-0400)] <fj4000> got a little busy
[13:26:43 EDT(-0400)] <hydee> we're having fun with css3 gradients and border-image
[13:26:47 EDT(-0400)] <colinclark> But there are certainly gaps in a few places.
[13:26:55 EDT(-0400)] <colinclark> Tool bars and buttons are, indeed, an issue.
[13:27:09 EDT(-0400)] <colinclark> I was pointed to Dashcode, which is their tool for building iPhone Web apps.
[13:27:12 EDT(-0400)] <fj4000> what about form contrls?
[13:27:35 EDT(-0400)] <colinclark> fj4000: As you'll see from that documentation, form controls are styled properly by the device.
[13:27:39 EDT(-0400)] <colinclark> No extra work required.
[13:27:58 EDT(-0400)] <fj4000> ok, so no worries about the difference between a native control and a form control
[13:28:05 EDT(-0400)] <colinclark> Yep, exactly.
[13:28:09 EDT(-0400)] <colinclark> Interestingly, the iPhone Web app HIG document provides lots of information about spacing, layout, etc.
[13:28:12 EDT(-0400)] <hydee> we were looking at drop-downs specifically. the iphone deals with it one way, but safari on iphone another.
[13:28:23 EDT(-0400)] <fj4000> and on-off sliders
[13:28:29 EDT(-0400)] <fj4000> as opposed to radio buttons
[13:28:35 EDT(-0400)] <fj4000> or checkboxes
[13:28:40 EDT(-0400)] <colinclark> Dropdowns should be styled as the standard "wheels of time" spinner.
[13:28:54 EDT(-0400)] <hydee> okay, that's the safari on iphone way
[13:29:10 EDT(-0400)] <colinclark> Anyway, I was pointed to Dashcode...
[13:29:23 EDT(-0400)] <colinclark> And you can see the occasions where they've had to include their own graphics to replicate native controls.
[13:29:35 EDT(-0400)] <colinclark> Interestingly, there is a license that accompanies the code generated by Dashcode.
[13:29:42 EDT(-0400)] <colinclark> I'll have to run it by our lawyer.
[13:29:44 EDT(-0400)] <hydee> and... we can use 'em?
[13:29:51 EDT(-0400)] <colinclark> But it's possible that we can basically rip things out of Dashcode and redistribute.
[13:29:57 EDT(-0400)] <colinclark> We shouldn't get our hopes up yet.
[13:30:02 EDT(-0400)] <hydee> on my itouch, i can take screen-shots and email them. is that a no-no ?
[13:30:10 EDT(-0400)] <colinclark> I'd say that's a no-no, yes.
[13:30:18 EDT(-0400)] <hydee> k
[13:30:18 EDT(-0400)] <colinclark> I mean, you can email them, sure.
[13:30:20 EDT(-0400)] <hydee> darn
[13:30:29 EDT(-0400)] <hydee> but can't use for imgs
[13:30:29 EDT(-0400)] <colinclark> But grabbing controls and then cutting them out and reusing them may not be cool.
[13:30:33 EDT(-0400)] <colinclark> So let's try to stay away from it, yes.
[13:30:45 EDT(-0400)] <athena> colinclark: i was asking earlier today about the mobile FSS effort and what kind of things are included in it
[13:30:48 EDT(-0400)] <hydee> let us know about dashcode soon - that'd be great.
[13:31:12 EDT(-0400)] <colinclark> 1 sec
[13:32:04 EDT(-0400)] <fj4000> athena: the more obvious things coming with mobile FSS would be themes for devices
[13:32:14 EDT(-0400)] <fj4000> but we've got our sights on more than that
[13:32:21 EDT(-0400)] <athena> yeah, it seemed like you might
[13:32:28 EDT(-0400)] <fj4000> stuff that concerns the experience as well as look n feel
[13:32:48 EDT(-0400)] <athena> from the name i originally assumed maybe it was sort of a mobile parallel for the FSS we already know and love, but it seems like you're all talking about broader topics
[13:32:59 EDT(-0400)] * colinclark (n=colin@192.42.249.7) has joined #fluid-work
[13:33:09 EDT(-0400)] <hydee> also, one thing we're asking ourselves: can we assume ppl will upgrade to iphone 3.0 (and therefore have safari 4). some css3 stuff doesn't work on the current iphone webkit version, but we'd be happier to use the new tricks
[13:33:25 EDT(-0400)] <fj4000> muuuuuuch happier
[13:33:32 EDT(-0400)] <athena> will this stuff all work on not-iphones too?
[13:33:38 EDT(-0400)] <fj4000> it should
[13:33:46 EDT(-0400)] <colinclark> ok, back
[13:33:48 EDT(-0400)] <colinclark> sorry, i was going into a session and didn't want to drop my coffee
[13:33:50 EDT(-0400)] <colinclark> or my laptop
[13:33:53 EDT(-0400)] <athena> like a blackberry or whatever else it is that people use
[13:33:54 EDT(-0400)] <fj4000> the real question is not iphone specificle, more like WebKit
[13:33:54 EDT(-0400)] <colinclark> Ok... awesome questions.
[13:34:17 EDT(-0400)] <colinclark> So, Dashcode... I'll get Barnaby (our awesome pro-bono lawyer) to look at the Dashcode license next week when I'm back.
[13:34:27 EDT(-0400)] <hydee> cool
[13:34:40 EDT(-0400)] <colinclark> In the meantime, we should probably just assume that we're in an unacceptably grey area to grab iPhone-like graphics and reuse them.
[13:34:48 EDT(-0400)] <fj4000> ok
[13:35:02 EDT(-0400)] <fj4000> does this mean though
[13:35:02 EDT(-0400)] <colinclark> I have a contact here who will try to clarify the IP and licensing issue around using graphics.
[13:35:14 EDT(-0400)] <fj4000> that we wont grab them - just make them from scratch?
[13:35:21 EDT(-0400)] <fj4000> or does this mean no replication at all
[13:35:26 EDT(-0400)] <fj4000> including in the CSS
[13:35:39 EDT(-0400)] <colinclark> fj4000: No, it means we'll try to use Dashcode's graphics, assuming the license is appropriate.
[13:35:44 EDT(-0400)] <fj4000> ok
[13:36:00 EDT(-0400)] <hydee> what about the iphone 3/safari 4/css3 question - can we make the assumption a user will upgrade and therefore use fancier css3 stuff
[13:36:08 EDT(-0400)] <colinclark> If it's not appropriate, and Apple can't give us a clear license for their graphics, then we're going to have to get creative, and create our own affordances that aren't rooted in their IP.
[13:36:17 EDT(-0400)] <colinclark> As for upgrades...
[13:36:29 EDT(-0400)] <colinclark> I strongly suspect that every iPhone user will upgrade in short order.
[13:36:35 EDT(-0400)] <hydee> we thought the same
[13:36:37 EDT(-0400)] <colinclark> The OS 3.0 upgrade is free.
[13:36:45 EDT(-0400)] <colinclark> And it works on all phones, old and new.
[13:36:46 EDT(-0400)] <hydee> and like $10 for itouch?
[13:36:56 EDT(-0400)] <colinclark> Yep, $10 for the iPod touch.
[13:37:07 EDT(-0400)] <colinclark> It's probably also likely that most touch users will upgrade, too.
[13:37:09 EDT(-0400)] <colinclark> Maybe a bit more slowly.
[13:37:13 EDT(-0400)] <hydee> yes
[13:37:17 EDT(-0400)] <colinclark> For now, let's go with this approach:
[13:37:24 EDT(-0400)] <colinclark> We'll target the iPhone OS 3.0
[13:37:36 EDT(-0400)] <fj4000> = safari 4
[13:37:36 EDT(-0400)] <hydee> cool
[13:37:45 EDT(-0400)] <colinclark> Once we're feeling fairly solid with this, we may decide to create a simpler or gracefully degraded version for iPhone OS 2.0
[13:37:53 EDT(-0400)] <colinclark> If we feel it is necessary.
[13:38:01 EDT(-0400)] <colinclark> It's pretty likely that by then no one will be using 2.x
[13:38:19 EDT(-0400)] <colinclark> OS 3.0 roughly equals Safari 4, yes.
[13:38:47 EDT(-0400)] <colinclark> athena: You had a question.
[13:39:12 EDT(-0400)] <hydee> fj4000: colin was suggesting we chat with clayton again about semantic markup and how aria's 'role' tag might be helpful there
[13:39:13 EDT(-0400)] <colinclark> What will mFSS include? Will it work on non-iPhones?
[13:39:20 EDT(-0400)] <colinclark> athena: Did I miss any other questions?
[13:39:20 EDT(-0400)] <athena> colinclark: yes, generally
[13:39:29 EDT(-0400)] <athena> no, just generally curious about the effort
[13:39:46 EDT(-0400)] <colinclark> fj4000 and hydee can probably tell you more about what ideas they're bouncing around right now...
[13:39:52 EDT(-0400)] <athena> what you're doing, how much it overlaps with current uportal initiatives, whether we can be involved in some way
[13:39:59 EDT(-0400)] <hydee> athena: we're thinking we'll add some extras to fss that help with mobile layout, and create themes for specific devices
[13:39:59 EDT(-0400)] <colinclark> But it's still early, so if there's stuff you want or are curious in, now's a good time.
[13:40:15 EDT(-0400)] <colinclark> We're starting with the iPhone, but we'll definitely create themes for other platforms.
[13:40:19 EDT(-0400)] <athena> neat
[13:40:19 EDT(-0400)] <hydee> athena: any ideas welcome!
[13:40:33 EDT(-0400)] <athena> so uPortal has had theoretical framework-level mobile support for years and years
[13:40:37 EDT(-0400)] <colinclark> Unclear if we'll do Blackberry, since their browser is pretty lame. But it'll definitely be possible for others to create new themes.
[13:40:43 EDT(-0400)] <colinclark> athena: yep
[13:40:48 EDT(-0400)] <athena> but it was sort of designed too early, so it didnt' get exercised much
[13:40:54 EDT(-0400)] * laurel (n=laurel@dsl-207-112-65-132.tor.primus.ca) has left #fluid-work
[13:41:00 EDT(-0400)] <colinclark> yeah
[13:41:00 EDT(-0400)] <athena> and then once it became relevant, well, it turns out it's a little broken
[13:41:34 EDT(-0400)] <athena> however! that issue has bubbled up towards the top of unicon's cooperative development queue, which makes it increasingly likely that it'll get fixed
[13:41:40 EDT(-0400)] <colinclark> ah, cool
[13:41:41 EDT(-0400)] <athena> i'm kind of hoping sometime in the really near future
[13:41:48 EDT(-0400)] <hydee> athena: what framework is being used?
[13:41:50 EDT(-0400)] <colinclark> Well, this is good timing!
[13:41:53 EDT(-0400)] <athena> yes!
[13:42:04 EDT(-0400)] <athena> i personally think it'd be awesome for uPortal to ship with a mobile theme in 3.2
[13:42:23 EDT(-0400)] <athena> hydee: so far there isn't much that really exists for a real live theme
[13:42:37 EDT(-0400)] <colinclark> I guess the key is that a good mobile experience is a lot different from the desktop experience. So, at very least, we'll give you the CSS framework and JS supports to build a great mobile version of uP 3.2.
[13:42:49 EDT(-0400)] <athena> but they're really not hard to create, and since we're already using FSS i'm definitely interested in what you guys are up to
[13:42:57 EDT(-0400)] <athena> sounds great colinclark
[13:43:06 EDT(-0400)] <colinclark> hydee and fj4000 are bouncing around the idea of "filtering" techniques where we tag ordinary desktop content with extra semantics, and then can create a reduced version of a page suitable for mobile.
[13:43:16 EDT(-0400)] <colinclark> We just don't know how far we can get with this approach, but it's an option.
[13:43:20 EDT(-0400)] <fj4000> athena: we're trying to recycle as much of the FSS work you've already got
[13:43:23 EDT(-0400)] <athena> yeah, i saw that email
[13:43:44 EDT(-0400)] <colinclark> I guess in the case of uPortal, you've got the ability to deliver a whole different portal Theme suitable for a mobile device.
[13:43:52 EDT(-0400)] <colinclark> So in that case, mFSS will be cool
[13:43:53 EDT(-0400)] <athena> what we've played with in uportal so far is creating a theme that gives you a list of links to portlets which pull up each portlet individually
[13:44:11 EDT(-0400)] <athena> rather than displaying every portlet on the page like normal
[13:44:19 EDT(-0400)] <colinclark> We'll also probably write something that helps with detecting the client device and delivering the appropriate stylesheets for it.
[13:44:25 EDT(-0400)] <hydee> ah, interesting
[13:44:25 EDT(-0400)] <athena> gotcha
[13:44:36 EDT(-0400)] <athena> i don't know if anything uPortal currently has would be interesting to you guys
[13:44:47 EDT(-0400)] <athena> basically uPortal keeps a list of user agents and default themes for those user agents
[13:44:50 EDT(-0400)] <hydee> would love to see your mobile versions athena
[13:44:58 EDT(-0400)] <athena> which is theoretically also set-able on a per-user basis
[13:45:19 EDT(-0400)] <athena> once the correct theme is matched up for a user agent, that specific XSL set is used to render the content
[13:45:24 EDT(-0400)] <colinclark> cool
[13:45:54 EDT(-0400)] <athena> one quirk with the portal will be that while we can render a completely different layout, html, etc. for the portal chrome, we may or may not have any control over the contents of the portlets themselves
[13:46:12 EDT(-0400)] <athena> so while some portlets might be cool and render differently for a certain user agent, i don't think we could ever count on that
[13:46:36 EDT(-0400)] <hydee> not v familiar with XSL but is there control over placement of elements or does it take out/add things or?
[13:47:01 EDT(-0400)] <athena> so i don't know if it would be likely that non-mobile specific portlet content would render appropriately enough inside that mobile FSS frame, or whether we'd need to consider adding a SAX processor to clean up content, or what
[13:47:32 EDT(-0400)] <athena> hydee: the way uPortal works is that there's an XML "layout document" for a user that just contains information about what portlets a user wants to see and where they should go
[13:47:45 EDT(-0400)] <hydee> gotcha
[13:47:47 EDT(-0400)] <athena> then uPortal has an XSL that outputs HTML from that XSL
[13:48:01 EDT(-0400)] <athena> so yes, we have complete control over whether things are rendered and where they're rendered
[13:48:14 EDT(-0400)] <athena> the default setup has things like layout -> folders -> columns -> portlets
[13:48:18 EDT(-0400)] <hydee> and the 'layout doc' is matched with the detected device?
[13:48:25 EDT(-0400)] <athena> and for a given page, you see the contents of one folder
[13:48:36 EDT(-0400)] <hydee> ah, user specific
[13:48:38 EDT(-0400)] <athena> actually, it's possible to have one layout, but different XSL depending on the user agent
[13:48:47 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[13:49:04 EDT(-0400)] <hydee> neat
[13:49:06 EDT(-0400)] <athena> so for the mobile theme, we might instead only render one portlet on a page, rather than rendering a whole folder as a page
[13:49:25 EDT(-0400)] <athena> if this is stuff you guys are interested in i could write up an email describing how it works in uPortal or something
[13:49:41 EDT(-0400)] <hydee> athena will you be at the all hands meeting?
[13:49:59 EDT(-0400)] <colinclark> athena: Just catching up while also trying to pay attention to the session.
[13:50:00 EDT(-0400)] <hydee> that would be wonderful - it's definitely helpful to hear your process
[13:50:04 EDT(-0400)] <colinclark> But we're thinking about something in common here.
[13:50:15 EDT(-0400)] <colinclark> You said a SAX processor to clean up content...
[13:50:21 EDT(-0400)] <athena> so we'd definitely have the ability to mark up the main chrome differently, but the portal doesn't really have much control over the contents of any given portlet
[13:50:35 EDT(-0400)] <colinclark> One idea that struck me was that we could, theoretically, use the Renderer to re-work content.
[13:50:37 EDT(-0400)] <athena> colinclark: yes, i think that'd potentially be possible, though i'd worry somewhat about performance
[13:50:46 EDT(-0400)] <colinclark> Since the REnder specifically operates on plain old HTML as templates.
[13:50:55 EDT(-0400)] <colinclark> My guess is that it would just be insanely too slow, but it's a curious idea.
[13:51:07 EDT(-0400)] <athena> uPortal i think has some support for sax post-processing, though i'm not sure if that is applied before or after the portlets write out their content (or both)
[13:51:14 EDT(-0400)] <athena> yeah, that's my guess too colinclark
[13:51:15 EDT(-0400)] <colinclark> interesting
[13:51:22 EDT(-0400)] <hydee> and we were talking about pre-building re-rendered pages nightly or something
[13:51:46 EDT(-0400)] <colinclark> hydee: That would work for Engage, since we can be sure that our UIs are already Renderer-driven.
[13:51:48 EDT(-0400)] <athena> hydee: i wasn't planning to - i'm not generally around for fluid meetings. but if you guys think it'd be helpful to have a conversation at some point i can try and shake some time loose
[13:51:56 EDT(-0400)] <colinclark> Basically, you'd transform one template into another.
[13:52:13 EDT(-0400)] <colinclark> But in athena's case, she has no control over the portlets, so it would have to be done after data was rendered into the templates.
[13:52:16 EDT(-0400)] <hydee> athena: okay cool, an email explaining your process would be a helpful start. thanks so much
[13:52:16 EDT(-0400)] <athena> right
[13:52:34 EDT(-0400)] <athena> we'd probably be best off ensuring that non-mobile-specific content would render OK
[13:52:35 EDT(-0400)] <hydee> ah
[13:52:35 EDT(-0400)] <colinclark> athena: I could imagine some kind of per-portlet strategy
[13:52:44 EDT(-0400)] <colinclark> So if you've already broken up the portal into a page-by-page interface
[13:52:55 EDT(-0400)] <athena> and telling portlet developers how they could write mobile-specific content in an opt-in way
[13:52:58 EDT(-0400)] <colinclark> and you could mark portlets as being mobile-friendly or not...
[13:53:07 EDT(-0400)] <colinclark> then you could, perhaps, deploy the renderer to re-render smaller chunks of markup as needed.
[13:53:11 EDT(-0400)] <colinclark> But that's probably just crazy talk.
[13:53:21 EDT(-0400)] * laurel1 (n=laurel@dsl-207-112-65-132.tor.primus.ca) has joined #fluid-work
[13:53:35 EDT(-0400)] <athena> yeah i think all that would be possible, but maybe not very performant
[13:53:40 EDT(-0400)] <colinclark> lol
[13:53:59 EDT(-0400)] <athena> we're going to have to come up with a sample of some sort to work with so we can debug the uportal framework issues
[13:54:17 EDT(-0400)] <athena> if we get that set up, i don't know if that would be useful as a more concrete demo
[13:54:27 EDT(-0400)] <athena> especially since you all already have a nightly uportal build
[13:57:52 EDT(-0400)] <colinclark> hydee: Oh, one other thing just struck me.
[13:58:02 EDT(-0400)] <hydee> athena is there a url i could check out where i'd see a mobiley version of uportal?
[13:58:09 EDT(-0400)] <hydee> colinclark: yeah?
[13:58:17 EDT(-0400)] <athena> unfortunately not hydee - right now one doesn't exist
[13:58:20 EDT(-0400)] <colinclark> The latest Safari has some pretty hot support for HTML 5's <video> and <audio> tags.
[13:58:33 EDT(-0400)] <athena> but if we can get a default set up for debugging the framework issues i'll let you know
[13:58:34 EDT(-0400)] <colinclark> You probably saw my Twitter enthusiasm about it.
[13:58:50 EDT(-0400)] <hydee> yeah i looked into that stuff a little via capscribe work
[13:59:01 EDT(-0400)] <hydee> need to read more now that it's out there
[13:59:06 EDT(-0400)] <colinclark> In short, <video> is fully supported in Safari 4, and it's fantastic.
[13:59:08 EDT(-0400)] <hydee> anything in particular?
[13:59:16 EDT(-0400)] <hydee> awesome
[13:59:26 EDT(-0400)] <colinclark> You'll find that the JavaScript API for <video> is far richer than the one provided by QT, I think.
[13:59:43 EDT(-0400)] <hydee> sweet. only ogg and theora tho yes?
[13:59:47 EDT(-0400)] <colinclark> Honestly, I think you're going to want to move to <video> as soon as you can. There's just the question of browser support.
[14:00:03 EDT(-0400)] <colinclark> On Safari on Mac/Windows, you've got support for anything that QuickTime supports.
[14:00:09 EDT(-0400)] <hydee> browser support an issue unfortunately but still want to check it out
[14:00:18 EDT(-0400)] <hydee> oh really? that's great
[14:00:20 EDT(-0400)] <colinclark> Theora only on FF 3.5.
[14:00:24 EDT(-0400)] <hydee> ah
[14:00:42 EDT(-0400)] <colinclark> I guess there will be a process in OpenCast for deciding on browser support...
[14:00:52 EDT(-0400)] <colinclark> but this is clearly the way of the future.
[14:01:30 EDT(-0400)] <hydee> yes i hope the opencast community considers... this future
[14:01:33 EDT(-0400)] <colinclark> I sat in a session and watched a demo that showed how Flash's strangehold on the Web video market will evaporate over the next few years.
[14:01:36 EDT(-0400)] <colinclark>
[14:02:06 EDT(-0400)] <colinclark> I can't tell you how enthusiastic I am about it. You'll even be able to synchronize captions using <video>, and do all kinds of rich media compositions using plain old HTML, CSS, and JavaScript.
[14:02:17 EDT(-0400)] <hydee> haha. are you on the opencast list? big flv vs mpeg talk... need to read them more closely
[14:02:21 EDT(-0400)] <colinclark> Indeed, I think the vast majority of CapScribe desktop's functionality could be implemented on the web.
[14:02:30 EDT(-0400)] <colinclark> I am on the OC list; I'm a little behind.
[14:02:59 EDT(-0400)] <hydee> yeah it's busy. but worth voicing this stuff on the list...
[14:03:00 EDT(-0400)] <colinclark> Charles sent me a funny email this morning about finding someone who can "mentor us on HTML 5." But the good news is that we're not dependent on Apple for help...
[14:03:08 EDT(-0400)] <colinclark> They're just following the spec.
[14:04:05 EDT(-0400)] <hydee> cool, am looking fwd to reading more on html 5
[14:05:17 EDT(-0400)] <hydee> thanks for the updates/shared enthusiasm colinclark!
[14:05:40 EDT(-0400)] <colinclark> np
[14:05:41 EDT(-0400)] <colinclark>
[14:06:21 EDT(-0400)] <hydee> athena: thanks! keep us posted
[14:06:30 EDT(-0400)] <athena> will do
[14:10:26 EDT(-0400)] <hydee> colinclark: http://blog.dailymotion.com/2009/05/27/watch-videowithout-flash/
[14:10:29 EDT(-0400)] <hydee> html5 site
[14:11:12 EDT(-0400)] <hydee> found via opencast list, so there's a bit of discussion starting to happen there (yay)
[14:11:21 EDT(-0400)] <colinclark> i'll have to take a look
[14:11:42 EDT(-0400)] <colinclark> YouTube also have an HTML 5 version now.
[14:20:31 EDT(-0400)] <jamon> man ant
[14:20:34 EDT(-0400)] <jamon> ww
[14:23:05 EDT(-0400)] <colinclark>
[14:23:32 EDT(-0400)] <jamon> cannot get aptana 64bit on linux to build
[14:24:59 EDT(-0400)] <jessm> jamon: ping
[14:25:06 EDT(-0400)] <jamon> jessm: pong
[14:25:29 EDT(-0400)] <jessm> hiya – not related to aptana at all but... i was just thinking about the wiki and jira outage tomorrow night
[14:25:41 EDT(-0400)] <jamon> yes? want me to wait for a better time?
[14:25:53 EDT(-0400)] <jessm> it might be good to have someone (maybe me?) to have a look at it after to make sure it's on the up-n-up
[14:26:06 EDT(-0400)] <jessm> i think tomorrow p.m. is fine
[14:26:27 EDT(-0400)] <jamon> makes sense, i checked in my local upgrade, plugins all seem to be there
[14:26:43 EDT(-0400)] <jamon> will be hard to tell because 3.0 is a major new release, so things are different
[14:27:03 EDT(-0400)] <jamon> but layout seems to work, achecker shows about the same number of validation issues on both 2.5 and 3.0
[14:27:14 EDT(-0400)] <jessm> k
[14:27:27 EDT(-0400)] <jessm> i'll plan to be on IRC as much as possible during that time window
[14:27:40 EDT(-0400)] <jamon> sure, i'll be as well then
[14:27:42 EDT(-0400)] <jessm> others who have no life, please join in at 8p EDT - 10p EDT on friday
[14:27:59 EDT(-0400)] <jamon> heh, i'm still going out tomorrow night after I'm done
[14:28:01 EDT(-0400)] <jessm> i might be on more at the 10p end...
[14:28:22 EDT(-0400)] <jessm> jamon: i like it!
[14:28:44 EDT(-0400)] <jamon> sounds like a plan, you let the fluid-announce folk know?
[14:28:56 EDT(-0400)] <jessm> 'bout to send out the notice
[14:28:59 EDT(-0400)] <jamon> cool
[14:31:11 EDT(-0400)] <jamon> got it, thanks, good to go jessm
[14:49:19 EDT(-0400)] * colinclark (n=colin@192.42.249.7) has joined #fluid-work
[14:50:39 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[15:28:34 EDT(-0400)] <jessm> jamon: ?
[15:28:41 EDT(-0400)] <jessm> did you already upgrade JIRA?
[15:32:07 EDT(-0400)] <jamon> jessm: yes, last night, that's where the loss of tickets occurred
[15:32:15 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[15:32:31 EDT(-0400)] <jamon> but there's some integration stuff between the two i'm planning on checking when i upgrade confluence tomorrow
[15:32:54 EDT(-0400)] <jessm> jamon: yikes – i didn't get your email. i see now
[15:33:12 EDT(-0400)] <jamon> oh that's no good, hope you didn't loose any tickets
[15:34:39 EDT(-0400)] <laurel1> jessm: i did tickets yesterday that were not lost...much to my delight
[15:34:59 EDT(-0400)] <laurel1> not sure about others
[15:36:08 EDT(-0400)] <jessm> laurel1: sorry!
[15:36:42 EDT(-0400)] <laurel1> not lost - good thing
[15:36:43 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has left #fluid-work
[15:36:54 EDT(-0400)] <jessm> jamon: laurel1: hopefully the heads-up on the list will have better results with the wiki
[15:54:07 EDT(-0400)] <colinclark> yura: Hey, are you around?
[15:54:21 EDT(-0400)] <yura> hi colinclark , i m here
[15:54:25 EDT(-0400)] <colinclark> hey
[15:54:53 EDT(-0400)] <colinclark> I was thinking about next steps for our comparative import services...
[15:54:58 EDT(-0400)] <colinclark> You've got the Python version...
[15:55:09 EDT(-0400)] <colinclark> Antranig and David are working on the two different flavours of JavaScript.
[15:55:12 EDT(-0400)] <yura> yes, i v seen you mentioned it on the mail list
[15:55:19 EDT(-0400)] <yura> yep
[15:55:19 EDT(-0400)] <colinclark> One of the things I'm really curious about is being able to compare performance.
[15:55:26 EDT(-0400)] <yura> right
[15:55:42 EDT(-0400)] <colinclark> I'm wondering if you want to dive in and add some way to time the execution of your code.
[15:55:57 EDT(-0400)] <yura> you mean xml to json parsing?
[15:55:58 EDT(-0400)] <colinclark> And then perhaps also to create some larger test data sets, based on what Hugues gave us.
[15:56:02 EDT(-0400)] <colinclark> yura: Yep.
[15:56:31 EDT(-0400)] <yura> ya that sounds good
[15:56:38 EDT(-0400)] <colinclark> Getting some timings across each implementation will let us see, for example, how slow JS code runs on the server with Rhino, in comparison to something more mature like Python.
[15:56:51 EDT(-0400)] <colinclark> Awesome, thanks.
[15:57:13 EDT(-0400)] <colinclark> I guess for a larger data set, we could just sort of semi-randomly fill out a big xml document.
[15:57:26 EDT(-0400)] <colinclark> Maybe you or Bosmo1 have some ideas about how to tackle this.
[15:58:48 EDT(-0400)] <yura> colinclark: just to clarify: we want to time stand alone conversion or on the server with for example cherrypy?
[15:58:57 EDT(-0400)] <colinclark> yep, that's the idea
[15:59:06 EDT(-0400)] <colinclark> Let's do standalone conversion first.
[15:59:12 EDT(-0400)] <yura> ok
[15:59:18 EDT(-0400)] <colinclark> I'm less worried about the time to deal with standard web container stuff.
[15:59:36 EDT(-0400)] <colinclark> I'm most concerned about the raw cost of parsing and converting large data sets.
[15:59:47 EDT(-0400)] <colinclark> You can imagine that, for Engage, we'll probably want to regularly import data. And a lot of it.
[16:00:05 EDT(-0400)] <colinclark> A few years back, Michelle and I worked on a project that had similar requirements for data import and conversion.
[16:00:20 EDT(-0400)] <colinclark> And our importer was really slow on large data sets, and it was a huge showstopper... People wanted fresh data.
[16:00:42 EDT(-0400)] <yura> yes makes sense
[16:00:47 EDT(-0400)] <colinclark> In my mind, converting data is probably one of the single most expensive tasks we'll do in the services layer.
[16:01:50 EDT(-0400)] <colinclark> Cool. Let me know if you need anything specific. I'm sure Bosmo1 will be around to lend a hand where needed.
[16:02:00 EDT(-0400)] <Bosmo1> I will be here
[16:02:09 EDT(-0400)] <colinclark>
[16:02:58 EDT(-0400)] <athena> if you're looking for a useful tool to do transformations i'm sure drew wills would be more than happy to tell you all about cernunnos (what uPortal is using to handle it's import/export database to-and-from XML backup needs)
[16:03:13 EDT(-0400)] <colinclark> cool
[16:03:16 EDT(-0400)] * colinclark is gonna go grab a sandwich.
[16:13:34 EDT(-0400)] * colinclark_ (n=colin@192.42.249.135) has joined #fluid-work
[16:13:36 EDT(-0400)] <Bosmo1> We should have a number of approaches to compare on XML parsing soon
[16:35:07 EDT(-0400)] <jessm> jamon: ping
[16:35:20 EDT(-0400)] <jessm> jamon: let's have a skype call tomorrow if you have some time
[16:38:53 EDT(-0400)] <jamon> jessm: sure
[16:40:08 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[16:46:53 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[16:56:37 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[17:02:15 EDT(-0400)] * mtheoryx83 (n=mtheoryx@c-98-228-108-233.hsd1.in.comcast.net) has joined #fluid-work
[17:26:03 EDT(-0400)] * clown (n=clown@142.150.154.101) has left #fluid-work
[17:55:48 EDT(-0400)] * colinclark (n=colin@192.42.249.7) has joined #fluid-work
[18:12:59 EDT(-0400)] * alisonbenjamin (n=alisonbe@user129-185.wireless.utoronto.ca) has joined #fluid-work
[18:28:46 EDT(-0400)] * colinclark (n=colin@192.42.249.7) has joined #fluid-work
[18:54:42 EDT(-0400)] * colinclark (n=colin@192.42.249.135) has joined #fluid-work
[20:13:56 EDT(-0400)] * mtheoryx83 (n=mtheoryx@c-98-228-108-233.hsd1.in.comcast.net) has joined #fluid-work