maintained by Chris Nelson <firstname.lastname@example.org>
Last Updated Saturday, January 16th, 1999
events and work.
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:
Keep an eye out for Grendel screenshots coming soon to mozillaZine.
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 <email@example.com> is the stuckee for implementing nsIRegistry (**moz**IRegistry?), though dp expressed some interest in it.
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.
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).
Vidur Apparao has the DOM update this week:
Troy writes in with this update:
Daniel Nunes has this update for us from the Build/Release group:
A new mail/news overview page is online, with lots of info on where the project came from, and where it's headed.