You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.




status update

maintained by Chris Nelson <chrisn@statecollege.com>

Last Updated Saturday, January 16th, 1999

This status update page is updated every Friday evening or Saturday morning (but check back, because I may add in late updates on the weekend). To get updates and news throughout the week , I invite you to check out mozillaZine, a site I maintain devoted to Mozilla advocacy.

Previous Updates

Module Updates
XPToolkit
January 16th
Submitted by Peter Trudelle <trudelle@netscape.com>

Highlights

  • A big cooperative effort involving a dozen people appears to have removed all of our immediate blocks in resolving architectural and design issues such as how to extend frames and use the widget interface. We seem to have a plan and green light, at least for the short term. Special thanks go to Rick Gessner and his amazing Gecko team for helping to blaze a trail for us, and to David Hyatt, for being our lead scout on the trail.
Lowlights
  • None, this was really a super week!
Accomplishments
  • Got Solaris to build.
  • Extended the object frame so that it could support the instantiation of arbitrary widgets.
  • Figured out how menus are actually going to get

  • events and work.
  • Posted a public update of the XPToolkit Architecture doc.
  • Resolved widget vs frame issue.
  • Resolved tree widget vs. tree-as-table issue.
  • Met with Gecko team to resolve issues over how to proceed on platform parity work.  We now have the bugs identified, triaged, and the owners and platform helpers identified and working closely together.
  • Fixed a few platform parity Bugs.
  • Overhauled the Unix build pages and status page.
Decisions
  • The big architectural issue that had blocked so many engineers last week was on the use of frame vs widget interfaces, and how to extend frames.  The short story of what unblocks us is that some widgets will be new frame types, and some widgets will be actual widgets.  The distinction being that the new frames will (to some degree) live in the layout DLL, and the new widgets will be much more independent.   The mechanism we have agreed upon is that we need to live in the HTML frames construction code,  add  several new frame types, and get at them from XML.
  • Based on detailed analysis following the latest architecural/design decisions, we have reversed an earlier decision and now plan to implement Treeviews using  tables.  This will take about a third longer than the equivalent widget implementation, so we have eliminated some minor features to keep the schedule impact roughly the same, and allow us to still hit our planned milestones.
Issues
  • Rod Spears is  waiting on Tom Pixley's event propagation fix for views, so he can check in ListBox and ComboBox.
  • Rod is also waiting on Tom's focus model in the event state manager so he can get key events to his widgets.
People
  • Ramiro Estrugo is leaving XPToolkit, having accepted a position on the Gecko team. We'll miss him, but it is clearly the right thing for the project, so we wish him all the best.  Thanks for giving us all Linux boxes before you left!
  • Rod Spears has joined the XPToolkit team, coming from the Gecko team. Rod did a lot of the early architectural work for the XPFE, and also brings extensive knowledge of Gecko. We are looking forward to the boost this will give our team.
  • Scott Collins is onsite at least through Feb 2.
Grendel
January 15th
Submitted by Jeff Galyan <talisman@anamorphic.com>

Here's the latest on Grendel from Jeff Galyan and the Grendel page:

Right now, we're using the Swing built-in JEditorPane/HTMLEditorKit combo, which is doing an okay job for fairly simple layouts, but really isn't so hot on real complex layouts (like the Netscape DevEdge newsletter, for example). But it's a start. We do plan to do our own HTML, probably either a direct port of nglayout, or by building Java hooks to XPCOM so we can use nglayout without porting it. We haven't decided which yet.

So, we can open and parse local mail folders now, which is 1000% better than where we were before (nice interface, but no message display functionality to go with it). Next thing for me is to get the folder tree to display, then get the ability to send/receive mail via a server (both POP and IMAP), then I'm going to do some work with the addressbook stuff.

furball is real close to having the xml menu building working as well, after which, he's planning to move on to the xml dialog building. He will probably do the majority of the HTML parser/displayer work, and I'll jump in as needed, unless we decide to do a port of nglayout - that will probably require both of us pretty much full-time. Again, we haven't yet decided which option we're going to go with for that.

From the Grendel page:

Grendel has been cleaned up significantly from its original release state. These are the things that are currently working and fully tested:

  • The classic three-pane view of folders, message threads, and message body with message body display. The message display needs work.
  • A composition window.
  • Reads local Berkely mbox style mail folders.
  • Converts mail into formated HTML.
  • A working MIME parser.

Keep an eye out for Grendel screenshots coming soon to mozillaZine.

Libreg
January 15th
Submitted by Dan Veditz <dveditz@netscape.com>

Dan Veditz has this libreg update for us

There's been discussion about the need for a generic XP registry service (which is what libreg provides), but as an XPCOM layer to break the link dependencies. After discussions yesterday the tide seems to be leaning toward implementing it using RDF rather than libreg. This would have several advantages, such as interoperability with other parts of the product that already grok RDF and the ease with which RDF can aggregate multiple datastores.

This leaves the fate of libreg unknown. Possibly it will become another data store that RDF knows about, and the two can be merged. For compatibility with previous versions (and to forestall additional work) I'd like SmartUpdate to continue using libreg.

Bill Law <law@netscape.com> is the stuckee for implementing nsIRegistry (**moz**IRegistry?), though dp expressed some interest in it.

 
Software Update
January 15th
Submitted by Dan Veditz <dveditz@netscape.com>

Dan Veditz also has the "software update" update for us:

We've given up on the MozillaSourceClassic branch. The services we relied on were there, but the architecture is so different that it was pretty pointless trying to get the Java-less softupdate working there and then have to redo most of it anyway. The softupdt branch code has been merged, but it's not part of the build and doesn't work at the moment.

"libjar" porting has started -- that's the service that knows how to read .JAR files and parse the manifest and signature files (uses zlib to deal with the archive format). Up to now it hasn't been in the Mozilla tree because of its use of security calls to validate the signatures. For now we're leaving the signature-checking stuff out, and talking with the security folks about how to provide that service in a way that won't get us in legal trouble. libjar will also be required for signed JavaScript, so this is a shared service.

At the same time we're changing SmartUpdate to accept unsigned installs (with a BIG user warning) so it'll work in the security-less Mozilla world. When the JS folks figure out how signed scripts will work in Mozilla we can add signatures back in, but we'll keep the unsigned option (with a way to turn them off, probably).

 
DOM
January 15th
Submitted by Vidur Apparao <vidur@netscape.com>

Vidur Apparao has the DOM update this week:

  • I'm going through a pass to complete the Level 1 Core DOM - Attributes as Nodes, the Node::CloneNode() method, Document:: and Element::GetElementsByTagName(), etc. The hope is to get it complete by early next week, so I can do a similar pass with the Level 1 HTML spec.
  • Tom Pixley is slowly getting our JavaScript security story together, interfacing with the capabilities library and putting in support for per-method and per-property security checks.
NGLayout
January 15th
Submitted by Troy Chevalier <troy@netscape.com>

Troy writes in with this update:

  • Chris is working on scrolling table row group frames (tbody element).
  • Kipp changed the flow of control for reflow commands. Now the style system notifies the frame of inserted/removed/changed changes by invoking a nsIFrame member function. Then the frame generates a reflow command.
  • I added support for CSS2 box 'offsets' (left/top/right/bottom). It's not finished yet.

 
Build/Release
January 8th
Submitted by Daniel Nunes <leaf@mozilla.org>

Daniel Nunes has this update for us from the Build/Release group:

  • Build automation for nightlies on linux running more regularly
  • Working to get builds contributed from outside for the non-linux, win32, mac platforms.
Mail/News
January 15th
Submitted by Phil Peterson <phil@netscape.com>

A new mail/news overview page is online, with lots of info on where the project came from, and where it's headed.

 
Javascript
January 15th
Submitted by Scott Furman <fur@netscape.com>

Thanks to John Bandauer, the XPConnect runtime work is progressing. Reflection of methods and constants into JavaScript is now working. Simple calls from both native code to JS and vice-versa are working. Hardcoded interface description information is being used until the typelib code is ready. The required platform-specific code is only implemented for Win32 at this point and only some method parameter types are supported. Further information on XPConnect technology can be found here.

Volodya has done a bunch of work on the JavaScript File I/O object, and has posted an update of the File object spec.

Volodya is also an official owner of 'PerlConnect', a technology that allows JavaScript to directly interact with Perl objects.

 

Previous Updates