| <alecf_> | ah, ok intros... I'm Alec Flett, developer at Netscape working on the mail client, among other things |
| <Alan> | I am Alan Jones, mozilla fan and bug hunter |
| <url> | i'm Adam hicks, curious end user in salem, oregon and high on caffeine |
| <mscott> | i'm scott macgregor...i'm a netscape developer who works on the mail client (particularly on the networking side) |
| <simeon> | i stevemorrison, mozillazine lackey and concerned citizen |
| <call-151> | Dan McGuirk, no notable accomplishments |
| <Ben_Goodger> | Ben Goodger, big mouth, UI |
| <BenB> | Ben Bucksch, minor mail hacks |
| <alecf> | ok, so where do we begin? First questions? Chris? |
| is this thing on? | |
| <chrisn> | ok, everyone with questions, type '?' |
| <endico> | i'm Dawn Endico, lizard mozilla.org lackey |
| <chrisn> | We'll point to each of you in turn, and you get a question, and a followup |
| ok | |
| first, let me get two proxied questions out of the way | |
| Asa wanted to know: | |
| are there plans going on for tighter webmail integration? | |
| <alecf> | Oy. I can't answer that first one, sorry.... Netscape confidential... |
| <Alan> | hmmm |
| <alecf> | but wait |
| shaver is interested in a different kind of integration | |
| a mozilla thing | |
| he's thinking about screenscraping, and plugging that into mozillamail | |
| <chrisn> | screenscraping? (I know that would be Asa's followup!) |
| <alecf> | and making screenscraping modules for different webmails |
| It's really shaver's dream, not mine, so I don't have exact details... | |
| <kerz> | what is a screenscrape |
| <alecf> | oh, sorry.... dragging down HTML from the server, and parsing out relevant information |
| <Ben_Goodger> | cool |
| <chrisn> | ah |
| <Ben_Goodger> | you could do hotmail integration then ;) |
| <alecf> | so logging into some webmail system and pulling out folder lists, messages, etc, from the HTML that comes down |
| <kerz> | interesting |
| <chrisn> | next q: Are we any closer to knowing if Netscape will add mail/news to Navigator 5 as a plug-in component or included feature with the browser? |
| that from Gary D. | |
| <alecf> | chrisn: well, in it's current state, it's basically a plugin as it stands: |
| here's how it's layed out | |
| - DLLs are dumped into the components directory | |
| - XUL and JS are dumped into the chrome directory | |
| - the only thing that actually links it to the rest of mozilla is a call to open "messenger.xul" | |
| as to how Netscape is going to package that, I really don't know :) | |
| <chrisn> | alecf: but a lot of those calls could happen from within a webpage for example - will it be possible to route to another messenger? |
| another email app, I mean? | |
| <mscott> | i can jump in here and answer that question... |
| that ties into some url dispatching work that I'm doing....and yes it will be possible to have other applications registered to handle protocols and contents | |
| i.e. all mailto: urls you can have get kicked out to another application if you so choose | |
| but that is all work in progress right now | |
| <chrisn> | cool |
| <BenB> | how difficult is it to separate mailnews from the browser right now? |
| <alecf> | yeah, what's cool is that messenger's method for "registering" for things like that will be generic - and anyone can copy our methods of plugging in |
| well, we can't run without the layout engine, XUL and RDF... which is the core of the browser of course | |
| but the browser is totally independant of mail - there is almost no code in the browser that deals with mail as a "special case" | |
| (and those special cases will be worked out by RTM) | |
| <chrisn> | ok, let's turn to our first questioner, Alan... |
| remember, if you have a question, type '?' and you'll be added to the list | |
| <Alan> | alecf, mscott, could you say what your current priorities are for beta? |
| what additions/problems | |
| <mscott> | one of my biggest areas is uri dispatching. |
| <alecf> | My priorities are currently working on the Tree Widget for hyatt in the XPToolkit team right now, but I'm also trying to work out architectural issues in mail so others can implement the last few features and bugs before our first release |
| <chrisn> | ? - adding myself to the list |
| <Alan> | .... and will you make it in time :) |
| <chrisn> | ok, next questioner: kerz |
| <alecf> | well, aside from architecture issues (like mscott's URL dispatching) that the browser needs anyway, mail is pretty much "feature complete" in mail for our next "release"... |
| <chrisn> | kerz? |
| <alecf> | we're just fixing bugs to make it useable on a daily basis now, without crashing, dataloss, etc |
| <kerz> | Were you happy, annoyed, whatever, with the shift from mozClassic to NGL? |
| <alecf> | Personally, VERY HAPPY. working in this new codebase is a DREAM, especially compared to MozillaClassic |
| <mscott> | i'll second that...it has been so much more fun and much more challenging |
| <alecf> | it's very well architected, and everyone seems very focused on doing the "right thing" |
| <kerz> | cool |
| <alecf> | not to mention there were lots of things left to implement, instead of just tweaking what we had in MozClassic :) |
| <kerz> | Along those lines, how close are you in terms of features to 4.x |
| <alecf> | (again, answering from a mail perspective) We've got the bulk of basic features done, but lots of nicities are still missing: mail filters, searching, and LDAP |
| <kerz> | But the one main feature that everyone wants is in right? |
| <alecf> | these are the things we're waiting on - some will be implemented before release, others may have to wait until the next point release |
| kerz: ? | |
| <kerz> | That being muliple pop3 accounts |
| <mscott> | (mail filter UI is missing...but mail filters work) |
| yes! | |
| <kerz> | yay! |
| <mscott> | (that's in =)) |
| <alecf> | yes! multiple POP and IMAP and News all at the same time |
| <chrisn> | ok next questioner: myk |
| <mscott> | our mail client is finally all grown up =) |
| <alecf> | :) |
| <myk> | alecf: what possibilities exist (and what are the limitations) for developing an XUL app in pure javascript? |
| <alecf> | myk: now that shaver has landed his "JS Components" work, and necko is finally becoming totally scriptable, I'd say the possibilities are a reality |
| (I sound like marketing...) but anyhow | |
| It's incredibly easy to make a UI in XUL, and then call JS from there. And for heavyweight, componentized JS backend, the JS Components are great. | |
| I've often wondered how much of mail we could just write in JS, I think a large part of it, if we really wanted | |
| <myk> | is there any api that won't eventually (if not already) be made available to javascript? |
| (follow up) | |
| * Ben_Goodger | thinks brendan will be after alecf et al now |
| <alecf> | myk: we've been working really hard to keep mail as scriptable as possible.. I think probably 95% of our interfaces are scriptable .... it's older interfaces like gecko that probably won't be scriptable for some time |
| <chrisn> | ok, next questioner: me! |
| <myk> | thanks alecf |
| <chrisn> | (if you have a question, type '?' to get added to the list) |
| <zinebot> | SeaMonkey: 'shrike Linux Clobber' has changed state from Test Failed to Success |
| <chrisn> | alecf: you mentioned you're working on the tree widgets. 1) when do you expect to be at feature parity with 4.x's tree widgets in messenger? |
| in regards to responsiveness, functionality? | |
| <alecf> | I recently had to answer this question for management, and I'll answer it in two parts: |
| - for functionality, I think we're 4-5 weeks away. just an hour ago, hyatt helped me fix some massive scroll problems. The tree widget is pretty close to fully functional at this point, but it has alot of edge cases to work out.. | |
| - for performance, here's the deal: for small quantities of objects in the tree, say under 500, we're about the same speed as 4.x, which is great | |
| the problem is that we' don't scale well at all. it's quite usable up to about 2000 objects (such as mail messages) but it just keeps getting exponentially slower after that... but we have a plan: | |
| there is an idea floating around about rearchitecting RDF so that we can build and use content much faster. this in turn would make the tree much faster | |
| but in order to do that, there's ALOT of heavy lifting that must be done for RDF, XUL, and the tree.... we're not even going to start that until after the new year | |
| (and that's only if we can't find other ways to make it faster) | |
| phew, that was a mouthful.. :) next? | |
| <chrisn> | followup: cool. could you also comment on 1) the responsiveness of shifting columns and 2) adding, removign columns from view.... |
| by shifting columns I mean adjusting their widths and positions... | |
| <alecf> | not sure about the first part, but the second part probably won't come until after the real usability bugs are out of the way |
| <chrisn> | ok |
| <alecf> | not because it's THAT hard, but simply because of resources and priorities |
| ah | |
| <chrisn> | ah? |
| sorry - that's not a followup! :-) | |
| <alecf> | so for the first part, alot of the responsiveness problems may be rooted in the same thing that's making the tree slow in general |
| but I haven't found it too bad, just flakey sometimes | |
| <chrisn> | yeah |
| next questioner is simeon. If you have a question, type '?' | |
| <simeon> | most mail apps have similiar functionality - how does 5.0 differentiate itself, from both a developer's and user's perspective? |
| <alecf> | that's a toughy, but I'll try :) |
| from a user's perspective, we're trying to followup on the success of messenger 4.5 - we have a great, very usable product that alot of people like.... our first goal is to try to match that, | |
| from there, there are lots of 'low hanging fruit' that could make the mail client really cool, such as JavaScript filters, or other sort of smart-filtering things | |
| but to reach that point we have to have a good 'mail platform' | |
| from a developer's perspective, it's the greatest: the entire mail client is scriptable with JavaScript! what could be better? It makes it incredibly easy to customize and expand | |
| also, it's got a fairly straight forward architecture, I think, so it should make it easy to get up to speed | |
| <simeon> | so for developers, has being a part of mozilla.org open your eyes to develop issues for mail, or what this happen anyway? |
| <zinebot> | SeaMonkey: 'Win32 VC5.0Depend' has changed state from Horked to Success |
| <alecf> | It's hard to say - one of the great things about the team at Netscape is that there are alot of top-notch people who have been writing mail and collaboration software for years, |
| which means they have alot of really good perspective, experience developing the clients, customers, and so forth | |
| <simeon> | ok |
| <chrisn> | ok, next is kerz |
| <alecf> | but having the newsgroups to directly interact with users has been great as well |
| (people have brought some really cool, unique features to the table!) | |
| (I'm done, ask away) | |
| <kerz> | As far as the modularity (is that a word?) would it be possible to make something like an activeX control, or something similar to plug mail capabilities into other programs? |
| <alecf> | kerz: sure, |
| the wonderful thing about XPCOM is that it's still all standard C++ headers, and so forth, so with the right glue, I'm sure any class in the browser could be made accessable to COM (and thus activeX) | |
| <Ben_Goodger> | so someone could write a wrapper for it like the layout activeX control and you could access Mozilla's Mail BE from say, Delphi.. |
| <alecf> | sure - and since most of mail is done with interfaces, those interfaces could be exposed (possibly with glue code) through COM as well. |
| <chrisn> | kerz: followup? |
| <kerz> | nope |
| <chrisn> | ok, next questioner is me again. :-) |
| Are you comfortable with the capabilities of JS? since it's an interpreted language is it speedy enough to handle tasks you need to do? | |
| <alecf> | I've actually never had a complaint about JS speedwise.... sometimes manipulating the DOM has been slow, but gecko gets faster every day.... |
| and for capabilities, I love it, except for the fact that it's not syntax-checkable at build time. I find the language to be very flexable, and very powerful... | |
| <chrisn> | followup: along those lines, are you concerned about security issues that using JS might expose you to? Or is it adequately sandboxed to keep it protected from viruses, etc? |
| <alecf> | I think security is kind of orthogonal to JS itself: |
| security is pretty much allowing your code to cross some boundary into some other code.... now that JS is in it's (2nd? 3rd?) implementation generation, I'm pretty confident that the engine itself has the right architecture for security to be added.... | |
| it's the security itself that worries me a bit, but Netscape has had alot of experience in this area, so I'm not too woried there. Finally, | |
| now that the JS engine is open source, I think we have a much better chance of catching security problems before they make it into a released product - more eyes on the code, earlier access to the implementation, etc. | |
| <chrisn> | ok - just a sec. a third party has a followup... |
| wants to know about debugging js | |
| <alecf> | ok.... is there more to that? :) |
| <chrisn> | nope - sorry |
| I was just told to ask about it... | |
| I guess the question could be "what are your opinions about debugging js"? | |
| <alecf> | ok.... well, debugging JS is a little harder because there's no usable debugger (Yet - more on that in a sec) but within mozilla, |
| there are some really cool tools. One of my favorite is xpcshell - it's a JS shell that's XPConnect-aware - which means I can sit at the js> prompt and type JS to my heart's content, testing my C++ objects, JS routines, etc. | |
| as for the JS debugger, there's appearantly some school who's class has taken on the JS Debugger as a "class project" and will be working with mozilla to bring it back to life. | |
| <chrisn> | ok, let's go to our final questioner: kerz |
| <kerz> | No one asked, so I will, what are your feelings on the new skin? |
| <alecf> | ha! |
| I really like it actually. I think there are two important things here: | |
| - one of the things that really seperates NeoPlanet and Winamp out from other applications and really makes people remember them is that they're totally unique, very creative. they stand out. I think the new skin does that too. | |
| <kerz> | Cool |
| <mscott> | i also like the new skin a lot too |
| <kerz> | Thats all from me |
| <alecf> | - Mozilla lives in an XP world. We've spent years trying to conform to this operating system or that one... and look where it's gotten us.... I think it's great that we've taken a big risk and tried something totally unique. |
| also I like the fact that it looks like a browser you'd see in a movie, big simple buttons, etc :) | |
| <Alan> | (before you go) |
| <BenB> | lol |
| <alecf> | (I just checked 110 of 124 mail interfaces are scriptable - 89%!) |
| sure | |
| <Alan> | What percent of the code is platform specific? |
| <alecf> | none of mail is platform specific, which is fantastic if you ask me... as for the rest of the product, |
| <Alan> | i know hard question to quantify |
| impressive | |
| <ramiro> | i would say 5% |
| <alecf> | only the drawing code, and the file path code! |
| yes, a very small amount. | |
| <ramiro> | when it ships, probably 3% |
| <chrisn> | damn |
| <ramiro> | because natiive widgetry will be exorcised |
| <alecf> | yeah, it's made porting to new platforms (Photon, Be, OS/2, etc) relatively easy! |
| <Alan> | wow |
| <chrisn> | ok, I think that about does it |
| <Alan> | thanks for all the info! |
| <chrisn> | thanks to alec and ramiro and mscott for their time! |
| <alecf> | no problem! Glad to see lots of people interested. Keep using mozilla and FILE BUGS! |