status update
maintained by Chris Nelson <chrisn@statecollege.com>
Last Updated Saturday, January 16th, 1999
|
Highlights
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 <law@netscape.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. "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).
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.
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.
|