moon.mozpad.org is live and maintained by bsmedberg || mozilla.community.mozpad is live || Next meeting http://tinyurl.com/23fqmz moon.mozpad.org is live and maintained by bsmedberg || mozilla.community.mozpad is live || http://www.allpeers.com/blog/2007/08/22/mozpad-musings/ || Next meeting http://tinyurl.com/23fqmz +h bsmedberg plasticmillion: because I've been on vacation, I'm confused by your mozpad talk of SDK builds... what would they contain that the existing SDKs don't? did you read the blog post in the topic? plasticmillion: I think so I read everything that came across my feed reader, which I think included that bsmedberg: so what do you think of my idea? plasticmillion: I'm not clear on how the SDK is different from the existing SDK or "the existing SDK with improvements" bsmedberg: I'm not sure, I haven't looked at the SDK in a long time when I last looked at it, it didn't contain many interfaces plasticmillion: I changed it a couple weeks ago to the thing I had proposed in my blog... and the string API used was different from what Mozilla uses internally bsmedberg: who builds it currently, how often and for what Gecko versions and platforms? bsmedberg: anyway, the short answer is "I don't know" plasticmillion: you *can't* use the internal string api from outside libxul any more I've been wanting to discuss this with you for a while as you know plasticmillion: and it's being produced nightly for trunk the main point for me is not that we're going to change anything in the SDK at all, if it is already what it needs to be and packages are available for the platforms people want it's more about giving people a place to go when they want to use the Mozilla platform right now it's kind of homeless, wouldn't you agree? yes, but I'm not sure the answer is a product or at least, to define the mozpad project around a product what would you do? I want to define it around "developers helping developers" - write about how to use the existing sdk yeah, i haven't mainly because the windows sdk isn't quite right yet I just can't get my head around this without seeing the platform as a product with a proper name, website, documentation, marketing, etc. need to update the refplatform it's being built on bsmedberg: let me put it this way, why *not* set up Mozpad as the home for the SDK product? plasticmillion: why *not* get docs for how to use the sdk with different build systems sdk's do not usually translate to products plasticmillion: because the SDK... yeah it's a tool... you don't need it to write a XR app ummm the alternative is to build Mozilla yourself? or am I missing something? an srchived SDK does not a product make most app authors won't need to compile anything ok all they need is an editor + maybe "zip" and... packaging yeah I hear you the SDK is part of a bigger picture I think I made that pretty clear and if they do need a c++ component, they shouldn't need to build Mozilla this is as much as perception/marketing issue as a technical issue mfinkle: amen to that the sdk should be enough no one should ever need to build Mozilla, unless they were very very naughty ;-) frowns at mfinkle mfinkle: yes that was kind of my point thebot: settle down you bag of bolts but how is that a *product*? mfinkle: I want something analogous to Silverlight and AIR it sounds more like a how-to or rather, I think we *need* something analogous I think that mozpad needs to be the support infrastructure bsmedberg: and that entails what, exactly, in your mind? don't speak of silverlight the selling points there are not the SDK, but the support structure mfinkle: Silverlight, Silverlight, Silverlight :-p bsmedberg: fair enough silverlight and AIR are not the same type of things though I think download links to current SDKs for all platforms is very low-hanging fruit and I agree with bsmedberg mfinkle: they target the same market and so do we no they don't the sooner we accept that, the sooner we will be prepared to compete mfinkle: explain silverlight->flash AIR->desktop mfinkle: okay well MS has an AIR competitor you can run sliverlight inside AIR, cause silverlight is a plugin maybe it's .NET+VS.NET+Silverlight -Silverlight that's a detail back to SKDs the bottom line is that if someone wants to write a multiplatform internet-enabled app, they have a few rational choices one is the MS stack SDKs one is the Adobe stack and another is the Mozilla stack and right now we are a poor choice that's what I'd like to see us address plasticmillion: if that is your goal - take WebRunner and make a nice JS library let's not get distracted by the SDK... it's a part of the puzzle but I'm happy to accept that it's not the most important thing since most people aren't coding in C++ instant AIR competitor mfinkle: well that's basically what I'm talking about but it's a bit more than just a JS library e.g. documentation branding you say 'branding', but I think you mean 'marketing' well branding is part of marketing and 'evangelism' branding + evangelism = marketing, roughly speaking slapping a name and logo on WebRunner won't get you a cup of coffee hold on take a step back my understanding is that AIR also lets you write downloadable local apps not just providing a process to run web apps in so this isn't just about WebRunner that is to say, if I understand correctly I could write something like Songbird or Joost using AIR Gecko supports offline apps good luck writing Songbird in AIR how would deployment work in that case? JAR how do I install it? download it, copy it whatever come on, I'm talking about a consumer app have WebRunner register a mime type application/x-webapp nice mfinkle: so what are the issues with writing, say, Songbird using AIR? then WebRunner can take the JAR or ZIP or whatever and 'install' it somewhere no binary components hah! hence the need for an SDK screw that oh come come it's a competitive advantage for us get JS->C++ working like Python ctypes well you'd still need to write wrappers, right? and never write a C++ dll again e.g. we use FreeImage in JS how do I hook into FreeImage from JS? ah ok the wrapper is in JS gets it hmmm right and you mean to tell me AIR doesn't let you do that? no it doesn't get out of town seriousy? seriously, even our extensibility is unparalleled the cloest you could get is writing a plugin - webkit supports plugins bsmedberg: :-D ok now we're getting somewhere mfinkle: you think the product should be called WebRunner? is not tied to the name mfinkle: I totally buy into your approach that's basically my vision of how the app space is going to shape up over the longer term but there are still plenty of real-world issues that need to be tackled mfinkle: application updates, just to take an obvious example how will that work? of course there are lots of issues you could install a private firefox until we work out those issues, at least moz has 2 kinds of updates right now - we could use 1 or both plasticmillion: our toolbox (toolkit) gives us a lot of possibilities writing a jsctypes wrapper around FreeImage looks eminently doable, modulo some issues with binary data I'm not criticizing I'm just saying: there's a need for a forum to work on this stuff bsmedberg, mfinkle: explain to me what you think the role of Mozpad should be "Support structure for the mozilla platform" which means what, concretely? write lots of constructive things about the mozilla platform and ideas around the platform start at places like this - http://wiki.mozilla.org/WebRunner:Planning Mozpad itself does not need to be the information hub or center plasticmillion: docs/tools/interactive support docs - add to MDC support - use existing IRC and forums mfinkle: I think you are missing the psychological aspect I don't believe Mozpad should create new infrastructure of course there are mechanisms for doing all this but there is no chance of capturing mindshare without a brand and web presence outside of obscure Mozilla wiki pages, IMO but there are not enough bodies that will come making a real product out of it is the best way to recruit bodies, I think www.webrunner.org (or whatever) sure but first we need to be able to support it I was saying we should use www.mozpad.org but I'm not married to the domain either it has a tiny bit of momentum which is a plus trues to think of an existing structure s/trues/tries all the main webrunner domains are registered, unfortunately try 'spiffy.org mozpad should be about people, not products products can come and go or evolve mozpad should be about rallying the community around the moz platform well as you pointed out, there are already sites for docs, support, etc. so what is the role of Mozpad? that's what I'm struggling with right now? concentrate and unify the activities it's people, not "sites" there are too many divergent efforts - mozpad should try to focus people What we really need to "compete" is a sense that there are people who are around to support the mozilla platform. bsmedberg: I think we need a heck of a lot more than that well, those people actually do need to support the platform ;-) sure, but where are all the use cases of companies using XUL/XR now? case studies is prolly better term mfinkle: my point exactly here what I see: you guys are pursuing your personal vision of what the Mozilla platform should become ok, mozpad should be a place to collect and evangelize case studies and I happen to like the vision a lot but there is an unbelievable lack of information flow no one has any idea what you're up to there is no overarching vision being expressed to get people excited and make them want to participate but we are not hiding the info all we need is a conversation mfinkle: I think most marketing people would be amused with the characterization of their job as "not hiding the info" there is no Place To Go to find out about this vision, to get what you need to develop apps, to find other people's apps, etc. I am proposing to make Mozpad that place or somewhere else can be that place if you have a better idea but then the role of Mozpad is very unclear to me and we probably want to migrate whatever momentum we have to that new place I like that idea - and you didn't say 'product' or 'sdk' once :) heh or 'branding' I didn't say "Silverlight" either are you proud of me? very much okay well one issue is that I think the Mozpad membership has very very divergent views about what we are up to what the final goal is, etc. mfinkle: out of curiousity, what is your take on the IDE issue? I use 2 different IDEs wishes he could remember what XULExplorer does I doubt anybody will ever get me to an eclipse based IDE I'm not crazy about installing Eclipse either, I must admit what IDEs do you use? VS (less) and Komodo (more) can you debug JS in Komodo? Komodo IDE - yes (not sure about Edit) you can debug PHP running on server from Komodo neat well you know, I'm happy to make Mozpad all about Webrunner personally I think it's the right vision I wonder what other people will think mfinkle: so could you imagine Songbird being a WebRunner app? how about using the concept of webrunner, and not webrunner itself webrunner is merely a manifestation of the concept well one manifestation - there could be others manifestations make for tough sells I kind of disagree with that you're outthinking yourself don't make people think too hard I wouldn't want the discussion to get slowed down by webrunner slowed down in what respect? what discussion? "painting the bike shed" kind of thins s/thins/things small details heh so you don't want people slowing you down... is that what you mean? the stuff we just talked about are big picture things - and we need more people to comment on them and add to them I'm not so sure about that I need more "platform" ideas and less "where to put the about box" ideas what would you characterize as "platform" ideas? so far, you have done a good job keeping the discussion at "platform" level (in this IRC session) yeah because I don't know any of the nitty gritty I haven't even tried WebRunner right! but I think that some discussion of the nitty gritty is going to be a plus for you as well it's really up to you +h mariano I don't want to co-opt your project! sure, I agree but once we get the big picture covered I have been saying for a while that we want things that act like desktop apps but install like web apps you never answered my question about Songbird ok - thats what I'd call 50,000 ft level how would you deal with the fact that they have all that binary code? I usuallyc all that the 30,000 ft level taling at the webrunner level is 10,000 ft level the oxygen is pretty thin at 50,000 feet plasticmillion: we should improve our platform so that fewer apps need binary code +1 totally agreement the funny thing is that we all agree on this stuff but we still have the option, at least for a while, and ongoing with ctypes I don't think that any of us are doing a good job of communicating this though plasticmillion: yes, if we do it right, Songbird could be a WebRunner app I want AllPeers to be a WebRunner app too I *need* it to be a WebRunner app the way it is now is very problematic (or I wouldn't even be bothering with any of this) we have like 300,000 lines of C++ code granted 300,000 lines of Mozilla C++ is like 200 lines of normal C++ ;-) but still making all the networking stuff work from JS is going to be a massive challenge and we can contribute a lot mfinkle: I think the first thing we need is a clear articulation of this vision does anything like that exist? umm, is "webrunner app" and "xulrunner app" the same? KaiRo: in my understanding, no KaiRo: nope webrunner is a xulrunner app that hosts webapps thought webrunner was a website running in a <browser> bascially, while xulrunner has chrome permissions well a XULRunner app is a OS-specific binary mfinkle: ok, so why are you people talking of XUL apps to be able to be webrunner apps? that confuses all that, IMHO it doesn't have "chrome permissions", it has control over the whole system plasticmillion: who says that a xulrunner app needs binary code? chatzilla runs fine as a xulrunner app, being JS code only KaiRo: cause you have to deliver XULRunner a proper ChatZilla deployment would include XULRunner but it would be much much nicer as a WebRunner app KaiRo: I think we are talking about a niche somewhere between website running in a browser and a full blown XR app (even JS-only) plasticmillion: OK, sure, but some binary code needs to be there - ideally distributed in the shared-xulrunner-utopia KaiRo: exactly yeah, the runtime would be installed once mfinkle, bsmedberg: what do you think of XUL? does it have a future or should it be replaced with improved HTML? yes, but a shared xulrunner install is still something other than webrunner in my eyes ;-) oh, this discussion again plasticmillion: it's really too bad you weren't at the Paris devday ;-) plasticmillion: I think that we should gradually and carefully add the features of XUL to HTML needs to send plasticmillion an email about the next devday bsmedberg: I was arguing the same the other day bsmedberg: we actually have exactly the same vision, I think yeah, I still don't buy the "HTML could be XUL" vision bsmedberg: and believe me, very few people understand that vision mfinkle: et tu, Brute!? et tu mfinkle: I suppose you want to feed XUL into WebRunner apps? would rather kill HTML than XUL :P not really - the content are of webrunner can be pure html, but the toolbars, menus, sidebars, statusbars, dialogs, alerts would be XUL s/content are/contentarea crap mfinkle: and those toolbars, menus, etc. would be the same for all apps? interestingly, we once were happy to kill HTML elements from our XUL documents, now people come and want to reverse that again - but that's the usual run of things in IT, I guess nope, the webapp - or a client side mashup - would define them IT != software development mfinkle: okay so the webapp is delivering XUL, in your view? and sd is a big, big world not necessarily mfinkle: well, it's the same with big host servers and thin clients vs. power to the clients plasticmillion: think of greasemonkey mfinkle: you lost me webrunner has a greasemonkey-ish way of scripting the chrome greasemonkey-ish is a nice neologism and remember that greasemonkey is completely external from the webpage it changes but I'm still lost yes yes I know how Greasemonkey works mfinkle: that goes back and forth in waves... and it seems to me that the discussion about a generalized data format like RDF goes the same way, and this web vs. local world does as well (XUL vs. HTMl is just a fragment of this in my eyes) so i should be able to make a script that adds menus and toolbars to GMail (running in WebRunner) KaiRo: there are two real issues: application delivery and standardization in other words - I can mashup the webapp myself - extend it beyond a webapp plasticmillion: standardization of desktop is a myth, and so is a language to do that KaiRo: if we just take the tag set from XUL that is missing from HTML, make it combinable with HTML (which it already is) and deliverable over the web (which it already is), then where's the difference between XUL and souped up HTML? KaiRo: and from a marketing standpoint (sorry mfinkle) souped up HTML is a *much* easier sell plasticmillion: stadardization can help and block innovation,d epending on how you use it... your use sounds to me like blocking mfinkles: sounds like an overlay to me plasticmillion: if we make HTML be like XUL, the web will suck even more than it does already plasticmillion: yeah, but 10 times easier KaiRo: the formal process doesn't really matter in most cases, but the perception does mfinkle: can I see some code please? plasticmillion: just because websites will wrongly use all kinds of dektop app crap or is this just a figment of your deranged imaginations? ;-) KaiRo: define "website" is Gmail a website? plasticmillion: well, web apps are abuse of HTML anyways if so, why is, say, Thunderbird, which is a direct competitor, allowed to use "desktop app crap" but Gmail isn't ? plasticmillion: http://svn.mozilla.org/projects/webrunner/ mfinkle: ummm plasticmillion: have you ever made/used a plugin for chatzilla? ab gmail can never compete with Thunderbird, as local mail rocks and web mail is a sucky workaround for not having local mail available mfinkle: do have have to trawl though your whole source code repository? I just wanted to see an example of your overlay idea KaiRo: you are so 2005, my friend http://svn.mozilla.org/projects/webrunner/trunk/install/profiles/ I'm 2020, my firend :P KaiRo: I am officially making you my poster child for why we need better evangelism of the WebRunner approach gmail will be dead in its current form by then gmail.webapp is a zip with a 'webapp.js' file in it KaiRo: was that "my fiend"? very apt, if so and possibilites are that Firefox will be dead by 2020 KaiRo: >:-D and I probably won't shed a tear, because we'll create something better (Mozilla won't be dead) mfinkle: no I've never written a ChatZilla plugin but I was planning to give it a try I patched CZ and someone suggest I make my code a plugin insted instead but OTOH, people said in 2000 that email will be dead by 2007 and people said in 1007 that web will be dead by 2005 s/1007/1997 KaiRo: the point is that something like TB should be deliverable over the web that's what we're trying to achieve oh, I hope I don't have to participate the web sucks and the client rocks that's silly that is, for dynamic apps the problem is, the web has some very cool advantages, as do local apps I want the best of both worlds KaiRo: http://www.allpeers.com/blog/2007/03/22/the-future-of-applications/ HTTP and HTML are so one-dimensional, they suck for any sophisticated dynamic app mfinkle, bsmedberg: thanks guys, I need to do my homework... get up to speed on WebRunner mfinkle, bsmedberg: can you make it to the Wednesday meeting? I post some more thoughts before then I'll post oh, and if things like XMLHTTPRequests are supposed to make it dynamic, that one sucks even more than HTTP and HTML together plasticmillion: I'll be here apart from that I don't want my private data to be tranferred back and forth over the web every time I open private information on my private computer KaiRo: you're preaching to the choir there are several efforts underway to store data locally but that doesn't mean the code can't be delivered over the web data storage is a totally separate issue yes, but that doesn't make HTTP and HTML be anything else than a one-way mfinkle: cool well in most interactions the notion of client and server can be somewhat fluid we use HTTP for P2P interactions and it works just fine code over the web is no bad idea (as long as it's not forced to be updated every time I connect and is cached well locally and stuff like that) KaiRo: yeah, that's exactly right I think where mfinkle and bsmedberg are coming from is the same angle as you: "web apps suck" but they are asking the question, what can we do so they don't suck? plasticmillion: well, P2P is not very interactive, you still transfer full files etc. KaiRo: no, P2P just means two clients talking without a server e.g. we have P2P instant messaging P2P presence not just file sharing IM is very interactive plasticmillion: making web forms dynamic is almost impossible though without transferring all possible data I could display in any case to the client and do some ugly hacky JS or use XFOrms plasticmillion: yes, try to write an IRC client in HTML and you'll start to cry for a few weeks... I tried it and still suffer plasticmillion: umm, with real-world browsers and with a technology like XMLHTTPRequests that has 20x more overhead than data transfer? no, thanks XForms is more of a dead format tham XUL in my eyes remembers that he always gets grumpy when he's hungry and goes for something to eat ;-) KaiRo: yeah the point is to figure out what would be needed to make a good IRC client as a web app and do the stuff that needs to be done (extending HTML, better protocols, etc.) to make that possible plasticmillion: well, the main pain is you need a markup format that handles incremental updates, a webserver process that interactively stay open and holds a two-way connection with the client, so the client can send entered commands to the server-side process as easy as the server sends updated views to the client plasticmillion: and a traditional web server with traditional HTML markup badly fails there KaiRo: I agree this is one of the key issues that needs to be addressed plasticmillion: along with having invalid markup the whole time the connection is active as you can't send the closing tags "AJAX" is very appealing from a functional standpoint but from and architectural standpoint it's a horribly inelegant hack yes, the whole web app sphere is very hacky, as HTTP/HTML was never intended for incremental two-way communication wonders what mfinkle's favicon is meant to represent my computer broadcatsing my "message" :) seek help, dude :-p turns tail and flees