[Advocacy] Fair go.
Oliver White
Seen this? Apparently we are doing a rewrite from scratch:
But seriously, I'm just here to have fun, and I figure everyone else
is to. Ok, we might fail in producing a working Javazilla, I accept
that and everyone else in the team should, but if you (jwz) have
something to discuss, you can bring it up with us if you feel like it.
On a lighter note:
Kevin Kelley
On Mon, 20 Apr 1998 14:27:16 -0700, Jamie Zawinski <j...@netscape.com>
wrote:
>I've already explained in some detail why I think this notion of porting
>to Java is doomed; it was a few weeks back, in .general. Check out my
>comments on GTK, they're relevant as well.
>
>I'll try and combine it into a cohesive "don't reinvent the wheel"
>document one of these days, but basically, if I believed you were
>writing a "Java FE", that would be one thing. Or if you were working on
>mechanisms by which new modules written in Java could be added to the
>existing Mozilla code base with minimal disturbances. But so far, I
>haven't heard any description of what you're doing that doesn't sound
>like "wrap every entry point in Java with the eventual goal of
>translating all the C++ code to Java", and I think that' a colossal
>waste of time that will never go anywhere.
>
>I am willing to be convinced that you're not wasting your time, but I
>just don't see it. My take on what's going on is, Java is the latest
>new toy, and this effort is driven more by technophilia than by
>well-thought-out practicality.
>
>I would be happy to be convinced otherwise. Personally, I'd rather
>write Java code than C or (especially) C++ code. But that's not the
>world in which we live.
>
>In case it isn't obvious, this is just my opinion. I would not try and
>stop you from working on whatever you feel like working on, and I wish
>you the best of luck. I would, however, be a happier camper if I saw a
>whole bunch of smart people working on a project that I thought would
>*succeed* rather than one I think it fundamentally misdirected, which is
>why I even bother talking about it.
>
>--
>Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
For myself, I jumped into this group without spending a lot of time
thinking about the 'rightness' of the project. To me, porting
everything that's useful to java just seems like the obvious thing
to do.
Of course, there's practical considerations. Java seems to attract
more than its share of rank amateurs (OK, I'm ready to help!
uhh..what's a file?). At the other end, there's a tremendous
inertia built up in the procedural C camp: both in terms of
codebase and expertise. Trying to throw that inertia at an OO
language hits a paradigm wall, result being project failure and
bitterness against the 'new thing' that promised so much and
didn't deliver.
As far as fundamental direction, I like the phrase about trying to
herd squirrels. I think if there's more than one person moving in
the same direction, that's progress. Seriously, a lot of the talk
that's been going on sounds blue-sky and speculative. For instance,
I've heard quite a bit about wrapping all or part of the code in
JNI and it's like 'oh, yeah, we can do that', but nobody's popped
up and mentioned problems or experiences they had when they actually
tried something similar in the past. (I have tried wrapping native
code, and had problems, but admittedly I didn't try too hard)
So I think there's a lot of rude shocks and fallout waiting for
those who even last that long.
On the other hand, there's nothing fundamentally (fundament again!)
wrong with java as a platform; there are issues and pitfalls, but
that's true anywhere. And there are certain benefits. The trick,
as always, is to make the benefits pay more than the pitfalls cost.
Anyway, that's too much of the advocacy bullshit from me. The
question I have is, what can I do that will have the best effect,
where best is defined in terms of meeting my own desires.
I want a browser that starts fast, doesn't crash, runs java applets
without taking 5 minutes starting java, handles mail and news at
least as well as my favorite newsreader. If I can work towards
any of that, it's a net gain for me, even if nothing better comes
up.
Maybe I'd be best off focusing into work on a java plugin or
something. I honestly expected more interest in things java;
the tone of what I'm hearing is that it's just a toy, not suited
for 'real work'. Seems strange to me.
So what's up, anyway? Is this a real project, or should I look
somewhere else? There's at least a few people around here that
are qualified and seem committed. I'm going to be doing fairly
serious work along these lines anyway, might as well get some
synergy if there is any. On the other hand, if it's just a
spare time, learning experience, just for fun exploration type
thing, that's ok too, I guess.
Question, for anybody that can point me to info:
What useful work is going on, with relation to java and mozilla,
that I could get involved in? I've got a couple years in java,
and some more in C, and more yet in C++, and a lot of time.
Kevin
--
"Java in the Browser, ----- -- --------------------- Kevin Kelley
----- and ------------- -- ------------ Starlight Software Co.
the Browser in Java." --- -- --- http://www.ruralnet.net/~kelley/
Sandeep Hundal
Failing ???? who said anything about failing ? I know I can't make a big
contribution to this project yet, but I think even *thinking* about failing
is no the right way to go.
The way I see it, this project has a mission. And its not just to port
Netscape Mozilla to Java. The mission is to show the world that Java is now
a language which can eventually be on par with C/C++ . And on top of that,
by making this project a contributor to the free software community, we're
also showing to the world the advantage of that way of doing things.
You have a very popular brand name to work with, and you will have some
companies who would be very interested in seeing this project succeed (and
obviously those who don't). I think the world's eyes will be on us.
The message that is sent out after this project succeeds will have an impact
for a very long time folks. ...
Sunny
> ----------
> From: Al Sutton[SMTP:a...@alsutton.com]
> Sent: 20 April 1998 15:23
> To: Oliver White
> Cc: mozill...@mozilla.org
> Subject: Re: [Advocacy] Fair go.
>
> <<File: vcard.vcf>>
> It's Jamies view of things and as mozilla.org is his site then what he
> thinks goes up. I've tried to explain what we are doing, buthe seems to
> beleive that what we are doing will never be any use and we are doomed
> to fail (Oh Woe is me.... Woe is me....).
>
> I have no plans on failing, but I can't complete the project on my own.
>
> If nothing else this will be a learning experience for us all (and
> Jamie).
>
> Al.
> --
> Al Sutton
> (a...@alsutton.com)
>
> The views expressed are solely mine and not those of any company
> or organization with which I may be associated.
>
> All Junk/Bulk E-mail sent to any address in the alsutton.com
> domain will result in the sender being charged 1,000 pounds sterling.
>
Augusto Sellhorn
> I was part of a group here that wrote a mail/news reader in Java.
>
> Guess what, we couldn't make it go fast enough. The existing JVMs suck.
> (Microsoft's JVM is the best of a bad bunch, but it's still an order of
> magnitude too slow.) You haven't seen slow startup time until you've
> seen a couple hundred thousand lines of Java code try and pick itself up
> off the floor. It's enough to make you cry.
Just to add some balance here. Of course, just because you guys failed
in this effort doesn't mean it can't be done. We did after all
implement a "CAD" viewer CORBA based applet that renders very fast
under IE and (yes) Netscape. Of course, the Netscape version is slower ...
> It is a toy. Today. Maybe someday it won't be; I dearly hope so.
> I really do! I think it's a fine language. But it's *just not done
> yet*.
>
True on the *just not done yet*. Nay on the "it is a toy". If this is the
attitude from Netscape regarding Java then this is *really scary*.
Ramiro Estrugo
Jamie Zawinski wrote:
>
> Your faith is inspirational. I wish it was true that it could move
> mountains, I really do. But faith aside, the Earth revolves around the
> Sun, rewriting Mozilla from scratch in *any* language would be a
> mistake, and Java is not yet ready for serious application development.
>
> If you want Java to succeed, you need to work *on* Java, not *in* Java.
One day (on a previous job) sun folks came to visit trying to peddle a
JavaOS to replace the OS already embeded into some black box networking
devices.
We asked them why we should rewrite everything in Java when the devices
already sold like hot cakes ?
They looked at as funny and they said "Because its Java!"
-re
--
Ramiro Estrugo
Unix Communicator, Netscape Communications
Kevin Kelley
Jamie Zawinski <j...@netscape.com> wrote:
>
>Work on one of the free Java VMs. Make them go fast, and be portable.
>This means "hack in C" and possibly "become a compiler stud."
>
My first java project was a parser for java, in java. I started
with the Java Language Spec, the JDK, and Holub's Compiler Design
in C, and got a working parser. In another language, it would
have been a big deal.
Maybe the best thing now is to get a free-source jvm that works.
We definitely need such a beast. I'll follow up some, and try
to get involved.
>I was part of a group here that wrote a mail/news reader in Java.
>
>Guess what, we couldn't make it go fast enough. The existing JVMs suck.
>(Microsoft's JVM is the best of a bad bunch, but it's still an order of
>magnitude too slow.) You haven't seen slow startup time until you've
>seen a couple hundred thousand lines of Java code try and pick itself up
>off the floor. It's enough to make you cry.
>
You ought to consider releasing that couple hundred thousand lines.
I'd bet my nonexistent salary that we could turn it into working
product.
Of course there are issues with java; it's interpreted; the bytecode
is verified on startup; runtime linkage happens through string names;
but there are always ways to deal with it. Of course you can't just
write a C program in java syntax and expect it to do what the C
version would do.
How about it? Let the code out, if you're not using it. Somebody'll
end up doing the project anyway; you might as well get credit for
starting it off. It'll be a big help, having a chunk of code to
start from instead of having none. Give us something to laugh about,
too. <g>
>It is a toy. Today. Maybe someday it won't be; I dearly hope so.
>I really do! I think it's a fine language. But it's *just not done
>yet*.
>
I agree that it isn't done, but it is not a toy. Too many people
are betting the farm on it for that to be true. You're sounding
like the classic "we couldn't do it, so it can't be done", and
I don't buy that.
>Learning about pluggable JVMs would be very useful:
>http://www.place.org/~stevemw/java/mozilla-activator/
>
>Creating a Java layer on XP-COM
>(http://www.mozilla.org/docs/tplist/catFlow/extendmoz.html) so that
>one could write modules or plugins using Java would also be cool.
>Then, one could write new modules in Java, when those modules didn't
>have to be fast.
>
>Working on a Java-to-C translator, or a Java front-end to the GCC
>back-end, would also do a lot to improve the state of the art (then, at
>least, one could write real programs in Java, even though the "run
>anywhere" part of the myth would no longer be even paid lip service to.
>Though presumably that could come later, when either the JVMs improved,
>or CPU speed increased enough that the slowness of the virtual machine
>no longer mattered (don't laugh, it's happened before.))
>
I'll follow the links and see what I find. Thanks for the info.
Hani Suleiman
>Jamie Zawinski wrote:
>>
>> Your faith is inspirational. I wish it was true that it could move
>> mountains, I really do. But faith aside, the Earth revolves around the
>> Sun, rewriting Mozilla from scratch in *any* language would be a
>> mistake, and Java is not yet ready for serious application development.
>>
>> If you want Java to succeed, you need to work *on* Java, not *in* Java.
>>
>> --
>> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
>
>One day (on a previous job) sun folks came to visit trying to peddle a
>JavaOS to replace the OS already embeded into some black box networking
>devices.
>
Well it's Sun, what do you expect! Iys unfortunate for java that Sun
controls it, but who knows, things might change, one day. Here's to
open Java!
Hani Suleiman
On Tue, 21 Apr 1998 02:45:29 -0700, Jamie Zawinski <j...@netscape.com>
wrote:
>Sandeep Hundal wrote:
>>
>> You have a very popular brand name to work with, and you will have some
>> companies who would be very interested in seeing this project succeed (and
>> obviously those who don't). I think the world's eyes will be on us.
>Your faith is inspirational. I wish it was true that it could move
>mountains, I really do. But faith aside, the Earth revolves around the
>Sun, rewriting Mozilla from scratch in *any* language would be a
>mistake, and Java is not yet ready for serious application development.
>
>If you want Java to succeed, you need to work *on* Java, not *in* Java.
I just downloaded HotJava (Sun's java browser). Its 100% pure java,
and it runs faster than Netscape, and takes as long to load. Granted,
it doesnt 'feel' as robust, but I find very little to fault with it,
it certainly seems up to speed.
Hani
Sandeep Hundal
Ppl,
My point is that just coz you guys failed doesn't mean we have to too.
Some one has to start from scratch, and even if it fails, other people can
look at it and improve it based on new technologies and more experience.
You say that Java is a *toy* and it just won't work, well if everyone said
that, you wouldn't have a browser in Java at all would you ? Even later on.
As this project continues, people will adopt the latest tools and methods of
doing things, other people will join and suggest better ways of wrapping the
code. You guys had the resources of Netscape, we have (potentially) the
entire internet. And sooner or later, this project will work as people find
more solutions and make the browser more robust.
Do you think anybody would have been sent on the moon if people didn't have
dreams about going there, and everybody accepted that it couldn't be done
because there was no precedent, or the technology wasn't 'mature' enough.
When is technology ever mature ?
Sunny
Giao Nguyen
Jamie Zawinski wrote:
> > Question, for anybody that can point me to info:
> > What useful work is going on, with relation to java and mozilla,
> > that I could get involved in? I've got a couple years in java,
> > and some more in C, and more yet in C++, and a lot of time.
>
> concept, and to ease porting/bootstrapping on other platforms.
That's what us poor schlobs in the FE group are doing and not to
poop on anyone efforts but I agree with Jamie to some degree.
What we've been playing with (us java folks) has been
anticipating the furture to some degree. Something that I've
been hoping and have not yet mentioned is that by the time the
FE is done, the VM's are fast enough to handle the rest of the
code being moved over.
There's no reason to *wait* until the faster VM's arrive.
> In summary:
>
> * Work on making Java itself not be a toy;
> * Write new non-speed-critical modules in Java;
> * Do not port old code to Java. Don't fix what ain't broke,
> especially when you can't fix it anyway.
Jamie, this is alpha level code. What isn't broke? :)
Giao
Laurent Thérond
> Your faith is inspirational. I wish it was true that it could move
> mountains, I really do. But faith aside, the Earth revolves around the
> Sun, rewriting Mozilla from scratch in *any* language would be a
> mistake, and Java is not yet ready for serious application development.
>
> If you want Java to succeed, you need to work *on* Java, not *in* Java.
Your pragmatism is fair. I know we are not going to make Mozilla portable
converting it to Java. But, it's a first step. Don't you think Java is
ready for a given number of development tasks?
> --
> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
> (And there's no easter bunny, either.)
>
--
Laurent Thérond
lrth...@hotmail.com
"Specialization Is For Insects."
Oliver White
I think we can count on Sun not to make major changes to the Java
language, so there is definitly no reason to wait for a better JVM. As
for the "just do an FE" idea, with a good Program interface between BE
and FE, it won't make an ounce of difference - thus we increase our
chances of producing good componants.
Oliver White
Quite. But there is a demand for a Java implemented browser, and I
think we might as well do it, we're working for free and if anyone
else wants to help out (hint hint javasoft) they can.
On Tue, 21 Apr 1998 09:13:02 -0700, Ramiro Estrugo
<ram...@netscape.com> wrote:
>Jamie Zawinski wrote:
>>
>> Your faith is inspirational. I wish it was true that it could move
>> mountains, I really do. But faith aside, the Earth revolves around the
>> Sun, rewriting Mozilla from scratch in *any* language would be a
>> mistake, and Java is not yet ready for serious application development.
>>
>> If you want Java to succeed, you need to work *on* Java, not *in* Java.
>>
>> --
>> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
>
>One day (on a previous job) sun folks came to visit trying to peddle a
>JavaOS to replace the OS already embeded into some black box networking
>devices.
>
Oliver White
Information about standardising java and protecting it's future as a
development tool is here :-
http://java.sun.com/aboutJava/standardization/javastd.pdf
Jonathan Lennox
In article <353C6631...@netscape.com>,
Jamie Zawinski <j...@netscape.com> wrote:
>
>Working on a Java-to-C translator, or a Java front-end to the GCC
>back-end, would also do a lot to improve the state of the art (then, at
>least, one could write real programs in Java, even though the "run
>anywhere" part of the myth would no longer be even paid lip service to.
Cygnus is, apparently, working on the latter of those -- they have a press
release at <http://www.cygnus.com/news/rtjava-980331.html> saying they'll
have something by the fall of '98. Supposedly they get something like an 8x
speedup.
--
Jonathan Lennox
len...@cs.columbia.edu
Augusto Sellhorn
Jamie Zawinski wrote:
> If you think HotJava is all that, why aren't you working on it instead
> of Mozilla?
>
Jamie, are we irritating you ? I have a lot of respect for you and your group
but this statement is a little bit irrational don't you think.
1) You can't work on HotJava, there is no source code out
2) He was just referring that there's a "decent" Java browser that he uses,
nothing wrong with the statement. Hey, some people like Netscape, others IE,
some Lynx, Hotjava, etc ... What's wrong with that?
3) If we are here is because we like Mozilla and we want to work on it. That's
obvious. Do you say to the people in netscape.public.mozilla.wishlist, if
you like this and that in IE why aren't you working on it ?
> > Do you think anybody would have been sent on the moon if people didn't
> > have dreams about going there,
>
> Oh please. Spare me the religious ecstasy.
>
Could you please get off the "religious" stuff. I use Java at work for some real
work,
what are you impliying ?!?!? Just because we see Java solving a particular need
here
doesn't mean we are "fanatical". Oh and BTW I am religious, I go to church,
pray,
and all that stuff but that doesn't have anything to do with a programming
language.
Please!
I think you make valid points, but please tone it down a little bit. Putting
people's
opinions down like this just because you don't agree with them won't convince
anybody
about your fine points.
Thanks
Augusto Sellhorn
GE Harris Energy Control Systems
asel...@ccd.harris.com
Lee Daniel Crocker
Jamie Zawinski wrote:
> If comparing the port of a piece of software from one language to
> another to the *space program* isn't religion, I don't know what is.
> Someone's going to trigger Godwin's Rule soon, I can feel it.
Well, let's see, if we map Bill Gates onto Hitler and Java users
onto the Jews, then...nevermind. :)
Here's a completely different approach to doing the port that I
hinted at earlier, but will now propose full bore, and will
probably be shouted down for political reasons even though it's
technically more feasible and results in a better end product:
Start with the C++ code for Raptor. Compile it into all the
DLLs, each of which has a more-or-less fixed interface.
Write some small Java classes that wrap the functionality of
those DLLs using Microsoft's proprietary J/Direct, which makes
attaching a DLL to Java code like falling off a log. Build a
few small test front-ends (like the "viewer" program) that
exercise those Java objects. What you end up with is a set
of fully specified, functioning Java classes that only run
on Windows, and some working test programs that only run on
Windows. But the "working" part is important, and it would
only take a week or two, not months. This cannot be done
with JNI, because all the objects floating around among the
various classes are still C++ objects Java-ized by J/Direct,
but the DLLs still call each other directly, passing around
C++ objects.
Phase 2: Implement the DLLs, one by one. Test each step
with the hopefully-still-working test front ends. This phase
can be done even by the non-Windows folks (though it would
still be harder for them since they won't be able to test
their work). Take each of those "wrapper" classes and
implement it in pure Java, using the existing design. The
hybrid classes are still around for use in testing each of
the pure ones. Throughout this phase you have a working
product getting more and more pure as time goes by. In the
end, you end up with a pure Java version of all the classes
in Netscape's original design. It's important that no
redesign be done here: as ugly as the C++ might be, stick
with its original design until it's gone.
Note that the DLLs are still there and calling each other
even while they're being "purified": only the test front
ends are in pure Java; the DLLs still call each other
natively under the scenes. The test programs are
comprehensive enough to test all the functions of each
purified class; that it is impure behind the scenes
doesn't matter yet. It's only a matter of time before
DLLs start becoming disused and fall of the back end.
When every class is purified, there simply won't be any
more C++ objects foating around, and we move to Phase 3.
Phase 3: Now that it works, make it better. Put a nice
Swing front end on it. Redesign some of the classes that
were awkward because of C++. Add in Java applets, JavaMail,
whatever. Replace their sockets and threads with Java
sockets and threads. Start making it look like a product.
--
Lee Daniel Crocker <l...@piclab.com>
Lee Daniel Crocker
Al Sutton wrote:
> > This characterization of what I've been saying is beneath you.> As I thought that trying to halt projects by demoralizing people working
> on them because you don't beleive in the project was beneath you Jamie.
> --
> Al Sutton
If you can be "demoralized" by a man expressing his honest and
technically
experienced opinion, that's your problem, not his. This is the
Internet,
for Christ's sake; anything less than a death threat should be
considered
overly polite.
Lee Daniel Crocker
Al Sutton wrote:
>
> Lee,
>
> Your approach would be a valid one if all of the Java Mozilla developers
> were working on Windows and had J/Direct. It could also be valid if our
> only target platform was Windows.
>
> Unfortunatley neither of these is true and we have to ensure that people
> can develop and use what we have of Java Mozilla on at least Unix, Win32
> and Mac.
>
> I'm not a personal fan of J/Direct's proprietry stuff, but if the group
> felt it's what we should do then I would go with the idea.
Phase 1 could only be done on Windows. That's regrettable, and is
indeed
a downside of my approach. But if that's the only approach that's
actually
_doable_ in a reasonable time, sometimes you have to compromise on
politics
for technical feasibility. And the end result is the same: a 100% pure
Java product.
I'm not much of a J/Direct fan either, but it's there, and it works.
I'll
do this, then: I'll wrap 1-2 of the DLLs in a class, hack up a test
program,
and report on how fast and effective the process was, and try to
extrapolate
that into a product schedule. Could be interesting, or I could find out
that
I'm completely wrong, and it wouldn't work any better than our current
approach. But I suggested it, so it's up to me to do the work of
testing.
Lee Daniel Crocker
Al Sutton wrote:
> Jamie,
> Why are you trying to halt a project that would;
I really don't appreciate your continually slandering a good man.
Jamie is NOT "trying to halt" anything; he's expressing an honest
opinion that our project is infeasible. So what? That's his
opinion. Deal with it like a man. Argue your side, don't lie
about his.
Oliver White
I honestly thing this is just a standardisation issue.
On 22 Apr 1998 13:34:49 -0400, len...@news.cs.columbia.edu (Jonathan
Oliver White
Relax.
On Wed, 22 Apr 1998 10:35:41 -0700, Jamie Zawinski <j...@netscape.com>
wrote:
>Al Sutton wrote:
>>
>> I've heard enough of Jamie going "Ohhhh your never going to succeed"
>> without him giving good examples to get me a little rattled.
>
>This characterization of what I've been saying is beneath you.
>
>--
Oliver White
On Wed, 22 Apr 1998 17:19:46 -0700, Lee Daniel Crocker
<l...@piclab.com> wrote:
>Al Sutton wrote:
>> > This characterization of what I've been saying is beneath you.
>> > Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
>>
>> As I thought that trying to halt projects by demoralizing people working
>> on them because you don't beleive in the project was beneath you Jamie.
>> --
>> Al Sutton
>
>If you can be "demoralized" by a man expressing his honest and
>technically
>experienced opinion, that's your problem, not his. This is the
>Internet,
>for Christ's sake; anything less than a death threat should be
>considered
>overly polite.
This is true. Now please please please, without one last snappy
comeback, can you leave us in peace jamie? I'm really sorry I broke it
up and I'll stay out of this thread from now on, OK?
Stephen Fitch
Lee Daniel Crocker wrote:
> Phase 1 could only be done on Windows. That's regrettable, and is
> indeed
> a downside of my approach. But if that's the only approach that's
> actually
> _doable_ in a reasonable time, sometimes you have to compromise on
> politics
> for technical feasibility. And the end result is the same: a 100% pure
> Java product.
>
Steering clear of the Phase 1 choices for dev tools etc, it would be
good if we could maintain the cross platform nature of anything deliverd
from this project. Even if in the first instance that Windows 95 stuff
has to be used to bootstrap the whole process, because of the widespread
infestation of it, even to me it seems the logical basic building platform.
I'd be interested to here from anyone else with a Solaris or UNIX underlying
platform so that we can start to build ideas as to how to get the results of
the efforts on to the multiple platforms that I hope we would all like to
see it run.
Those interested in quality testing the cross platform delivery on Solaris can
drop me a line, I expect I might be able to cover both the SPARC and x86
platforms.
Some I suggest might also wan't to co-ordinate the MAC and other platforms.
The whole idea of this project it would seem to me would be to
create a cross platform result, but with quality on each. That
takes effort.
scf
--
The above is *my* opinion and comment, not that of Sun Microsystems.
--
Stephen Fitch | Applications & Languages - Product Support Engineer,
| Sun Microsystems Ltd, - Watchmoor Park, Camberley,
| - Surrey, UK, GU15 3YL,
| Stephe...@uk.sun.com - Tel: +44 1276 691974
Sandeep Hundal
> Al Sutton wrote:
> > > This characterization of what I've been saying is beneath you.
> > > Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
> >
> > As I thought that trying to halt projects by demoralizing people working
> > on them because you don't beleive in the project was beneath you Jamie.
> > --
> > Al Sutton
>
> If you can be "demoralized" by a man expressing his honest and
> technically
> experienced opinion, that's your problem, not his. This is the
> Internet,
> for Christ's sake; anything less than a death threat should be
> considered
> overly polite.
>
Fine, but we didn't come here to cuss each other. Forgive if I misunderstood
that. I think maybe I'm just naive for assuming that there'll be some mature
people here who want to work with code and contibute something towards the
internet community, instead of trying to diss each other just because they
don't have the same opinions. This mailing list was set up for people who
want to develop a browser version of Mozilla in Java.
1) We don't need people to tell us that we can't succeed. The technology
might not be 'mature' enough to develop Jazilla now, but I didn't get a mail
from Al saying that its slated for release next month either. This is an
ongoing project, like Linux.
2) We're not demoralized. Its no use even floating that idea. Instead I
would say that I (and probably others) are *more* determined to make this a
success just to show that we have the willingness and are determined, and
the technology is, and will be there. We just don't need people adding noise
just to continuously voice an opinion which contradicts why we're here in
the first place.
Sunny
Laurent Thérond
In article <353eb5e6...@news.mozilla.org>, o...@iinet.net.au says...
> This is true. Now please please please, without one last snappy
> comeback, can you leave us in peace jamie? I'm really sorry I broke it
> up and I'll stay out of this thread from now on, OK?
>
>
If Jamie challenges you, you should listen. He has been challenged before
and, believe me, his reaction was beautiful.
This is not a riddle, even if it sounds like one. Just try to learn a bit
more about Jamie Zawinski. It won't be that difficult.
L.
Sandeep Hundal
>When I present my considered, experienced, technical opinion of the
>feasbility of a project, and suggest that other projects would be
>more feasable and therefore more useful, you characterize me as
>attacking the free software ideal. Nice.
> --
> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
>
>
Jamie, there are things which are feasible, and then there are things that
you *want* to do, regardless of the challenges and obstacles. Please
understand the difference. This project will be feasible, Al and the others
are working towards it. Give them credit for that.
Sunny
Jamie Zawinski
Sandeep Hundal wrote:
>
> Jamie, there are things which are feasible, and then there are things that
> you *want* to do, regardless of the challenges and obstacles. Please
> understand the difference. This project will be feasible, Al and the others
> are working towards it. Give them credit for that.
Of course I understand that. But the fact that Al is (apparently)
driven by faith rather than practicality does not give him the right to
impugn my motivations as he has continually done in the last few days.
I have been utterly straightforward about my opinions and the reasons
for them, and his responses have been nothing short of intentionally
misleading innuendo.
I also think it's very important that *others* understand the technical
issues here, and that before someone signs up, that they should realize
that this project is not as easy as it is being portrayed. I'm not
posting for Al's benefit, because I know I'll never convince him.
Sandeep Hundal
anyone wants to contribute to any project, they can do so...and Al puts up
the patches on his page.. And yes, he maintains a list of the team involved,
but thats only for everyone's benefit. There is nothing that is compulsory,
everything is driven by consensus (to a certain degree) and voluntary work.
I gave him my details but I still haven't written a word of code or even
looked at the Mozilla code. Thats becoz I'm not a developer, but I'm trying
to learn Java and I'm willing to help out in other ways. But I've seen loads
of enthusism in this group. All you're trying to do is put a dampner on
things. People will realise the technical constraints automatically as they
become familiar with the tools and methods. I don't think you have to
highlight anything frankly.
Sunny
Kevin Kelley
j...@netscape.com (Jamie Zawinski) wrote:
>Sandeep Hundal wrote:
>>
>> Jamie, there are things which are feasible, and then there are things that
>> you *want* to do, regardless of the challenges and obstacles. Please
>> understand the difference. This project will be feasible, Al and the others
>> are working towards it. Give them credit for that.
>
>Of course I understand that. But the fact that Al is (apparently)
>driven by faith rather than practicality does not give him the right to
>impugn my motivations as he has continually done in the last few days.
>I have been utterly straightforward about my opinions and the reasons
>for them, and his responses have been nothing short of intentionally
>misleading innuendo.
>
>I also think it's very important that *others* understand the technical
>issues here, and that before someone signs up, that they should realize
>that this project is not as easy as it is being portrayed. I'm not
>posting for Al's benefit, because I know I'll never convince him.
>
This thread is turning into "can too" "can not" and I'm sorry I
contributed to it.
I agree with Jamie that there are technical issues, and I'm looking
for ways to deal with them. My feeling at the moment is that the
issues that will exist can be resolved. I can't prove that any
other way than by taking some large project that is imputed to
be 'impossible' and doing it.
I don't agree with Jamie that the fact that there will be technical
issues means that we should look for an easier project. My feeling
is that Java could use a 'trial by fire', to demonstrate that it's
a capable real-world solution, and to hopefully improve the state
of the art. (Well, it's had trials by fire already; what I mean
is it needs to _win_ one. <g>)
Any 'technical issues' that anyone can suggest as being difficult
and in need of solving, I'd appreciate hearing. I'll try to avoid
the content-less arguments in the future, though.
[and now, back to the studio]
--
Kevin Kelley - Starlight Software Co.
http://www.ruralnet.net/~kelley/index.html
Al Sutton
>
> Al Sutton wrote:
> >
> > inapproptiate for someone of his position.
>
> I have never said a *thing* about the DOS port, one way or another,
> and I'll thank you to stop putting words in my mouth.
>
Not publicly, but from what I've hear from the guys over there your
doing the same thing as you did to me initally (i.e. saying there's no
point to the project and it shouldn't get started via private Emails).
If that's wrong then I appologise, but it's the impression I have been
given by them.
> > Myself and others have put in a fair amount of effort so far into
> > writing code and organising the project, and I find it surprising that
> > someone who would appear to be a supporter of the free software ideal is
> > trying to stop people working on the Java Mozilla project.
>
> When I present my considered, experienced, technical opinion of the
> feasbility of a project, and suggest that other projects would be
> more feasable and therefore more useful, you characterize me as
> attacking the free software ideal. Nice.
>
If you had said "I don't think it's feasible, but go ahead and try" or
"my considered, experienced, technical opinion is that it may not work"
I would have not minded as you would have put your point forward in a
reasonable manner.
However, you approached the subject by saying things basically saying
the project is a waste of time and that we should all pack up and go off
to do something else (in the process drawing an analogy between
programming in Java an heart surgery, saying that Java doesn't work
today and therefore we shouldn't bother with it, and being highly
negative about Java in general).
I would welcome your viewpoint (as I would welcome anyones, even Bill
Gate's) if it was put in a constructive wayt, but all I have seen so far
is negative comments without examples that hold up to discussion.
My reason for saying that you seem to be against freeware projects is
that this project has the potential of being something really great, but
you seem intent on saying "No it won't work, Java isn't ready for it"
until everyone gives us. I'm afraid that the more you say it, the less I
(for one) take notice, until you come up with some concrete reasons why
it can't work.
> --
> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
I would like to end this here Jamie.
I would like to ask every
Al.
--
Al Sutton
(a...@alsutton.com)
The views expressed are solely mine and not those of any company
or organization with which I may be associated.
All Junk/Bulk E-mail sent to any address in the alsutton.com
domain will result in the sender being charged 1,000 pounds sterling.
Al Sutton
>
> Sandeep Hundal wrote:
> >
> > Jamie, there are things which are feasible, and then there are things that
> > you *want* to do, regardless of the challenges and obstacles. Please
> > understand the difference. This project will be feasible, Al and the others
> > are working towards it. Give them credit for that.
>
> Of course I understand that. But the fact that Al is (apparently)
> driven by faith rather than practicality does not give him the right to
> impugn my motivations as he has continually done in the last few days.
> I have been utterly straightforward about my opinions and the reasons
> for them, and his responses have been nothing short of intentionally
> misleading innuendo.
>
What gives you the idea I'm driven by faith?, I'm driven by the fact
that I believe that we can succeed at this because of the capabilities
of Java and the technologies that are available now (JavaMail, The
Crypto Libraries, etc.).
I'm a contract Java developer by nature, and I would hope that after
following Java's development since before JDK 1.00 was released I would
be able to see a lame project when I come accross one (and no, I
definatley do not beleive that Java Mozilla comes under the lame project
catagory).
As for the attitude of my reponses then I beleive we have both been over
enthusiastic at times due to our strong beleifs at opposite ends of the
spectrum.
> I also think it's very important that *others* understand the technical
> issues here, and that before someone signs up, that they should realize
> that this project is not as easy as it is being portrayed. I'm not
> posting for Al's benefit, because I know I'll never convince him.
>
I don't think it would be realistic to ask everyone to understand all of
the technical aspects of the project before they sign up because it is a
large project. I'm not going round convincing people to work on the
project, as I beleive you should not go around discouraging people.
If someone is interested then I'm happy for them to join in. If they
need help then other people in the group will support them, and if they
come accross problems the group can discuss it an look for solutions.
Now, can we get on with Development and stop having a slanging match.
Al.
P.S. I would also be grateful if the rather negative comment about the
java project could be removed from the mozilla.org web site as it paints
a very negative picture of the project and you haven't given the people
who beleive this can be done a chance to respond.
> --
> Jamie Zawinski http://people.netscape.com/jwz/ about:jwz
--
Gregory R. Block
> This thread is turning into "can too" "can not" and I'm sorry I
> contributed to it.
Well, then let's help steer it away from that.
> I agree with Jamie that there are technical issues, and I'm looking
> for ways to deal with them. My feeling at the moment is that the
> issues that will exist can be resolved. I can't prove that any
> other way than by taking some large project that is imputed to
> be 'impossible' and doing it.
Then let me step forward with a few things you can all do to make your lives
easier.
1) Get the best tools on the market. Don't settle for JDK, don't settle for any
cheap knock-off freeware, because when it comes down to it, you're settling into a
*huge* undertaking, and you're going to need every ounce of help from your tools
that you can get. If that means going around to vendors and beating them up to
give you a free license version or ten, then so be it. You've got to try, though.
2) Make a very solid architectural analysis before you do any major development
work, because the cost of recoding will be painful, and you're going to do it *a
lot* if you spend your time following the C interfaces around.
> I don't agree with Jamie that the fact that there will be technical
> issues means that we should look for an easier project. My feeling
> is that Java could use a 'trial by fire', to demonstrate that it's
> a capable real-world solution, and to hopefully improve the state
> of the art. (Well, it's had trials by fire already; what I mean
> is it needs to _win_ one. <g>)
That's true in some cases. Look at Netscape's own work on building products out
of our own technologies, like JavaScript - essentially eating our own dogfood, as
it's said.
And while that has helped the JavaScript platform immensely, then look back and
decide if the result is up to the standards you're going to set. Trial-by-fire
infers heat and pain. You have two options - work indirectly on the tools by
building Jazilla, or work directly on the tools so that Jazilla is easier as a
next step.
The choice, obviously, is yours.
> Any 'technical issues' that anyone can suggest as being difficult
> and in need of solving, I'd appreciate hearing. I'll try to avoid
> the content-less arguments in the future, though.
Solid and robust preprocessing, build, and dependency management. A god-like
debugging environment. Detailed error analysis. A detailed architectural
specification and project plan with milestones (even if there are no dates
attached).
Make your life easier by preparing your toolset now, or suffer later. Plan your
architecture now, or pay the price again and again.
I have to say, I don't see evidence of that yet, and you're in for a world of
hurt, because Jamie's got some damn good points - large scale projects in java are
damn painful, right now.
:plur,
Greg
Joshua E. Rodd
Jamie Zawinski wrote:
> Work on one of the free Java VMs. Make them go fast, and be portable.
> This means "hack in C" and possibly "become a compiler stud."
Many of us are doing just that. But this is a newsgroup for discussion
of a Mozilla implementation for the Java platform.
> Sorry, but if you want Java to be real, that's what needs to be done.
> Writing more code *in* Java won't get you there.
Gee, I've written some nice code in Java. It works just fine, thank you.
The code was running on a 486DX/33. While it wasn't superfast,
it did the job.
> I was part of a group here that wrote a mail/news reader in Java.
>
> Guess what, we couldn't make it go fast enough. The existing JVMs suck.
> (Microsoft's JVM is the best of a bad bunch, but it's still an order of
> magnitude too slow.) You haven't seen slow startup time until you've
> seen a couple hundred thousand lines of Java code try and pick itself up
> off the floor. It's enough to make you cry.
Is it? While I only have experience with OS/2's JVM, Java code executes
plenty fast for me. In any case, by the time Java Mozilla is usable for
the
masses (next year?), CPU power will have increased so much it won't
matter.
If we follow this "it's-not-fast-enough" idea through, then we need to
get
out our assemblers and start coding the "right" way.
> It is a toy. Today. Maybe someday it won't be; I dearly hope so.
> I really do! I think it's a fine language. But it's *just not done
> yet*.
By the time Java Mozilla is done, the Java VMs will be more then good
enough.
>
> Writing an FE in Java might be an interesting thing to do, as proof of
> concept, and to ease porting/bootstrapping on other platforms.
Agree, and will do.
> Working on a Java-to-C translator, or a Java front-end to the GCC
> back-end, would also do a lot to improve the state of the art (then, at
> least, one could write real programs in Java, even though the "run
> anywhere" part of the myth would no longer be even paid lip service to.
> Though presumably that could come later, when either the JVMs improved,
> or CPU speed increased enough that the slowness of the virtual machine
> no longer mattered (don't laugh, it's happened before.))
Agree, and am.
--
Heil Gates,
Joshua
When e-mailing my privately, please replace the ibm.net in my email
address with usa.net.
Joshua E. Rodd
Augusto Sellhorn wrote:
> True on the *just not done yet*. Nay on the "it is a toy". If this is the
> attitude from Netscape regarding Java then this is *really scary*.
Jamie is speaking on behalf of himself as an individual. He is
espousing his opinion of Java.
Netscape as seen through their press releases wants to migrate
to a world filled with Java.
Kent C. Dickinson
Jamie Zawinski wrote:
> I also think it's very important that *others* understand the technical
> issues here, and that before someone signs up, that they should realize
> that this project is not as easy as it is being portrayed.
Mr. Zawinski, there is an article in today's (4-23-98) Investors Business Daily
that deals with Corel Corp. and their efforts to make a O/S and browser and
office suite with Java Beans for NC's and the base code for the O/S is Linux,
the Base code for the browser is Mozilla, and the base code for the office suite
is PerfectOffice. (I would put a link to Investors Business Daily but they are
only on AOL, and I receive the print version.)Now maybe this article is totally
wrong, which is possible with Newspapers, maybe I am misreading it?
But if it is correct and is what Corel is doing then, They are showing some deep
faith in Java and it is possible that with licensing matters that this could be a
great advance for open source.
Correct me if I have missed something here.
Sincerely,
Kent C. Dickinson
>
>
Augusto Sellhorn
Joshua E. Rodd wrote:
>
> Augusto Sellhorn wrote:
> > True on the *just not done yet*. Nay on the "it is a toy". If this is the
> > attitude from Netscape regarding Java then this is *really scary*.
>
> Jamie is speaking on behalf of himself as an individual. He is
> espousing his opinion of Java.
>
I realize that. I said "if this is the attitude from Netscape ..." just
because Jamie is rightfully an influential individual at Netscape and
assumed his opinions either reflect or influence technical people at
Netcape. I shouldn't make this generalization tough so thanks for the note,
I don't want to give the wrong impression. I hope I didn't insult anybody,
if I did, sorry Jamie ...
> Netscape as seen through their press releases wants to migrate
> to a world filled with Java.
>
Sometimes I wonder tough ... I hope you are right.
-Augusto
Kevin Kelley
"Gregory R. Block" <gbl...@netscape.com> wrote:
>
>Then let me step forward with a few things you can all do to make your lives
>easier.
>
>1) Get the best tools on the market. Don't settle for JDK, don't settle for any
>cheap knock-off freeware, because when it comes down to it, you're settling into a
>*huge* undertaking, and you're going to need every ounce of help from your tools
>that you can get. If that means going around to vendors and beating them up to
>give you a free license version or ten, then so be it. You've got to try, though.
>
robust tools. However, the ones I've worked with in the past (and
I admit it's been a while since I evaluated anything) were the dog's
breakfast. I don't want to get into guinea-pigging for the various
tool manufacturers; you spend more time debugging their stuff than
your own.
There's a school of thought that holds that over-reliance on debuggers
and hand-holders is a sign of poor skills or bad design. In the
absense of (as you say) god-like tools, I'll comfort myself with
that. But I seriously hope that we'll be able to come up with solid,
reliable tools.
>2) Make a very solid architectural analysis before you do any major development
>work, because the cost of recoding will be painful, and you're going to do it *a
>lot* if you spend your time following the C interfaces around.
>
Again, I agree with one hand and disagree with the other. Absolutely,
a solid architecture is critical. However, it's not possible (IMHO)
to do that wholistically, up front; it's got to evolve. Systems
change, needs change; the developer's understanding changes; new
ideas emerge; the architecture has to be able to adapt. Requiring
that it be nailed down up front is just unrealistic, I believe.
Especially in the internet environment, where things are never the
same from one day to the next.
Meta-state patterns, designed-in adaptability, avoiding brittleness,
Dependency Management (in the comp.object sense), things like
that are critical.
Then there's the fact that we're trying to build on an existing
base. Saying up front, before we even understand the base, that
we have to create a new architecture, doesn't sit right. I think
we should be able to use the fact that the existing architecture
appears to work as a base on which to build. Once we've established
ourselves on the existing plateau, then it'll be time to move up
a level.
>
>> Any 'technical issues' that anyone can suggest as being difficult
>> and in need of solving, I'd appreciate hearing. I'll try to avoid
>> the content-less arguments in the future, though.
>
>Solid and robust preprocessing, build, and dependency management. A god-like
>debugging environment. Detailed error analysis. A detailed architectural
>specification and project plan with milestones (even if there are no dates
>attached).
>
All that stuff goes good with any project, in any language. Can't
help but agree, in principle. Still, I'm not sure what this has to
do with the difficulties java, in particular, will give. I mean,
for example error analysis: I'm looking at the Assert/error/log
stuff in nspr now, and the existing system is basically if (DEBUG)
die on failed asserts, and logging messages to a stream based on
whether it's info, warn, error, or fatal. I can't see it as being
difficult to duplicate that level of error handling.
Build and dependency management becomes a lot easier when you're
writing to a single platform definition instead of a plethora. The
need for the preprocessor likewise diminishes.
The project plan and milestones, well, I'm new to the bazaar format,
I don't know quite how that should fit in. I know we need one, but
I'm not sure whether anybody'd pay attention to it. The best thing
I can think of is just to let everybody swarm over the system, and
document what we find, hopefully pulling out a coherent picture.
Tools to help there would be great; I just tripped over the LXR
cross-reference thing at mozilla, that's a pretty nice way to jump
around the existing system.
>Make your life easier by preparing your toolset now, or suffer later. Plan your
>architecture now, or pay the price again and again.
>
>I have to say, I don't see evidence of that yet, and you're in for a world of
>hurt, because Jamie's got some damn good points - large scale projects in java are
>damn painful, right now.
>
I appreciate the comments; Netscape has my respect for doing good
things in several senses. Any information that comes out of their
past experiences is valuable.
Gregory R. Block
> I'd be strongly in favor of this, provided it means getting good,
> robust tools. However, the ones I've worked with in the past (and
> I admit it's been a while since I evaluated anything) were the dog's
> breakfast. I don't want to get into guinea-pigging for the various
> tool manufacturers; you spend more time debugging their stuff than
> your own.
Often true on the cutting edge of any software development. However, don't think for a
moment you won't be spending that same time debugging the JDK as you would debugging
VisualAge or Symantec CafePro. The JDK isn't exactly what I'd call a halo of code
purity.
> There's a school of thought that holds that over-reliance on debuggers
> and hand-holders is a sign of poor skills or bad design. In the
> absense of (as you say) god-like tools, I'll comfort myself with
> that. But I seriously hope that we'll be able to come up with solid,
> reliable tools.
Okay, I'll wager that in small development groups where people know what they're doing,
that's true.
You ain't got that.
You've got a net development effort, where submitted code will come from every level of
skill - from people who are using your project as the ultimate "Learn Java in 21 Days"
effort to people who remember when Java wasn't a puppet for Sun. (Which is more a
comment about Sun than Java, really, 'cuz I'm not a Java-hater)
So you're, frankly, going to need all the hand-holding you can get. And the more
people get involved, the more dependent you're going to be on your tools. This is true
of large development efforts just as much as small ones with random skill levels. As
well, you're going to need things that *any* large development project needs - who has
the responsibility of code review? How do people know when they've broken something?
Mozilla is easy in comparison; there's a CVS server and a bunch of code reviewers who
can decide whether or not your changes have impact all over the place.
You're starting over, planning on building a browser - a huge undertaking by any sense
of the word. Give yourselves a break and plan it out before diving in with some kind
of rush to get "something" out the door, or you'll suffer from prototype syndrome.
Prototype syndrome is what happens to me, occasionally, at customers. You build
something that's meant to be a prototype and it becomes a product.
> However, it's not possible (IMHO)
> to do that wholistically, up front; it's got to evolve.
It has to evolve *from* something. Right now, I see nothing. I see lots of jabber in
a newsgroup about what people are going to be thinking of doing, and what they're
working on, but I see no cohesion other than this newsgroup. I see no goals, no
milestones, no plan that is both centrally accessible and referred to as gospel.
That's not saying I think you're doomed to fail. It's saying I think you're all in for
a world of hurt when things start going a bit left of center.
> Systems
> change, needs change; the developer's understanding changes; new
> ideas emerge; the architecture has to be able to adapt.
So develop an architecture. I see an ASCII-art version of an "architecture" that
reminds me of the maps I used to get from a friend in London which gave me directions
on how to get to his house from Camden Town. I see a task list of two tasks, one
current, one completed.
In short, I see no real planning. What, then, should I expect?
> Requiring
> that it be nailed down up front is just unrealistic, I believe.
That's what people who've never worked on huge projects say, frankly. Project planning
or an architectural analysis of a problem isn't nailing down a solution, it's *nailing
down a problem*. It's guaranteed to be wrong, but it at least provides a general
roadmap; even if it doesn't list all of the sidestreets, it tells you where the freeway
is and goes.
> Especially in the internet environment, where things are never the
> same from one day to the next.
Now imagine using it as your development environment.
Remember: The Internet sucks. Repeat after me. It sucked when I was a geeky hacker
getting busted at 13, and it sucks today. It sucked *less* then, that's all.
You've got to analyse the whole problem, and devise a way from getting to point A to
point B that everyone can agree on and reference. The problem isn't as bad now because
everyone's focused on getting NSPR done so that people can start parallelisation of
tasks, but it's going to get worse unless someone starts taking it seriously.
I see people taking the idea of Jazilla seriously; I don't see the serious handling of
the project.
> Then there's the fact that we're trying to build on an existing
> base. Saying up front, before we even understand the base, that
> we have to create a new architecture, doesn't sit right.
Frankly, sitting in back, before you even have a good understanding of the existing
architecture, doesn't sit right.
> Once we've established
> ourselves on the existing plateau, then it'll be time to move up
> a level.
You haven't described the level you're *reaching for*. That's the problem. You can't
consider step two until you've gotten to step one, but show me the document that
outlines, so that everyone can actually understand (and can't say "but I thought you
meant X") what step 1 actually *is*.
> All that stuff goes good with any project, in any language. Can't
> help but agree, in principle. Still, I'm not sure what this has to
> do with the difficulties java, in particular, will give. I mean,
> for example error analysis: I'm looking at the Assert/error/log
> stuff in nspr now, and the existing system is basically if (DEBUG)
> die on failed asserts, and logging messages to a stream based on
> whether it's info, warn, error, or fatal. I can't see it as being
> difficult to duplicate that level of error handling.
A lot more has gone into the development of Mozilla than a few asserts.
> Build and dependency management becomes a lot easier when you're
> writing to a single platform definition instead of a plethora. The
> need for the preprocessor likewise diminishes.
Total disagreement. But that's an IMO, based on how people develop new functionality.
> The best thing
> I can think of is just to let everybody swarm over the system, and
> document what we find, hopefully pulling out a coherent picture.
I don't see people documenting. I see people attacking bits of code. *shrug*
> I appreciate the comments; Netscape has my respect for doing good
> things in several senses. Any information that comes out of their
> past experiences is valuable.
Jamie may not have the polished usenet facade that I manage, but it's doubtful that
Jamie was hacking terminal servers to get that access when he was my age. ;) Still,
Jamie is one of the few to voice his opinion on the subject who was responsible for a
great deal of work in Navigator.
I don't care if he's got poor word choice, bad breath, or if he's one of those bitches
off of Aliens with acid for blood, he should be taken seriously. His comments are damn
valid, and people need to start looking at the what's and why's of what they're doing
before just jumping in and doing it.
All in my humble opinion. The opinions herein cannot be inferred to have any
relationship with my parent company or my opinions on other projects within the Mozilla
universe. All rights reserved. Objects in the rearview mirror may appear to always
have room for meatloaf.
:plur,
Greg
Gregory R. Block
> I'd just like to make a few points in response to your mail;
Well, it's news to me. ;)
> 1) I'm trying to establish groups for working on sections of the code,
> and trying to ensure that people mail the list with what they are
> starting to work on before they start work on it. This way will should
> be able to ensure we don't duplicate effort.
It's not a matter of effort duplication - it's a matter of code standards, direction, and planning. You establish two groups; group
A's implementation uses method A, group B's implementation uses method B. Group A could have prevented a rewrite to method C had they
known that four steps down the road, their performance (that thing you can't really manage easily in Java because the profilers all
suck) is causing serious problems, or because the VM they selected may have working features where the JDK has bugs and requires
workarounds, or for many other reasons.
Sticking to the architecture gives you a generalised overview. It does not give you a project plan. It doesn't say what your goals
are, it doesn't say what to and not to do.
> 2) Most of the high level design decision have already been made.
Then it should be documented, frankly. You're going to have people coming in and out of this project, and it's unfair for them to know
everything. And the first time you get someone saying "But I thought we were...", I'll say "I told you so". You *must* treat this
like a real development effort - there's too much work to do to not do that. You're not giving yourselves a fair chance at making it
work if you don't.
> We are
> attempting to port Mozilla into Java use the structure of the C/C++ code
> as our design. As issues come up that mean we need to deviate from that
> then we can address them, but our plan is to follow the exsisting
> design.
You're going to have them. All over the place. Surely you can see that just with your work in NSPR.
If you're going to do it this way, *stop after NSPR*, review what you learned, look at what didn't work, and then decide if that's the
way you want to tackle the whole project. Imagine ten little groups of people working on various bits. Once you start introducing
dependencies, you're going to start seeing these problems, even if you don't see them now.
And if you won't listen, nobody can help.
> 3) Code review is done by the group (in the same way as most other free
> software). Anyone can download the code and check over it, bringing up
> issues as they arise.
That's not the issue. The issue is one of project management, coding standards, and verification before checkin, rather than a
"worksforme" attitude of checkin.
> I hope this answers your questions.
Hmm. I cannot and will not get involved in the port; I've got my hands tied with MozillaWorld and The Frontend I'm planning. So I'm
not *really* asking questions; just trying to get you guys to think some of what you're doing through before diving in to an empty
swimming pool. I can't say I like the way you guys are doing the work so far, and I hope that it doesn't continue along this path,
because even if you're successful in your plans, at this rate, it won't have been a fun ride.
:plur,
Greg
Sandeep Hundal
>I can't say I like the way you guys are doing the work so far, and
I hope that it doesn't >continue along this path,
>because even if you're successful in your plans, at this rate, it
won't have been a fun >ride.
Nobody said that it would....
Sunny
Al Sutton
>
> Al Sutton wrote:
>
> > I'd just like to make a few points in response to your mail;
>
> Well, it's news to me. ;)
>
?:)
> > 1) I'm trying to establish groups for working on sections of the code,
> > and trying to ensure that people mail the list with what they are
> > starting to work on before they start work on it. This way will should
> > be able to ensure we don't duplicate effort.
>
> It's not a matter of effort duplication - it's a matter of code standards, direction, and planning. You establish two groups; group
> A's implementation uses method A, group B's implementation uses method B. Group A could have prevented a rewrite to method C had they
> known that four steps down the road, their performance (that thing you can't really manage easily in Java because the profilers all
> suck) is causing serious problems, or because the VM they selected may have working features where the JDK has bugs and requires
> workarounds, or for many other reasons.
>
> Sticking to the architecture gives you a generalised overview. It does not give you a project plan. It doesn't say what your goals
> are, it doesn't say what to and not to do.
>
I'm trying to apply the divide and conquer method of project management
to the project in that we are splitting the tasks down and down into
atomic sections (Mozilla splits into NSPR, FE, etc.. NSPR then splits
into Threads, IO, etc.. IO splits into..... (you get the idea)).
I understand that this may introduce some cross section inefficiencies,
but if group B say "Hey, it would be better if we did x" (In the same
way Kevin is talking about the change to the PLBase64 stuff) then we can
iron those out. (find & grep will allow us to see where the call is used
:)).
> > 2) Most of the high level design decision have already been made.
>
> Then it should be documented, frankly. You're going to have people coming in and out of this project, and it's unfair for them to know
> everything. And the first time you get someone saying "But I thought we were...", I'll say "I told you so". You *must* treat this
> like a real development effort - there's too much work to do to not do that. You're not giving yourselves a fair chance at making it
> work if you don't.
>
Agreed, which is why we have written the code so we can run JavaDoc over
it and generate the technical docs. This coupled with the documentation
for the main C/C++ source code tree (the design of we are trying to
stick to as closely as possible) should allow most people to get up to
speed quite quickly.
As for documentation of decisions we always have the mozilla.org
newsgroup archive to fall back on.
> > We are
> > attempting to port Mozilla into Java use the structure of the C/C++ code
> > as our design. As issues come up that mean we need to deviate from that
> > then we can address them, but our plan is to follow the exsisting
> > design.
>
> You're going to have them. All over the place. Surely you can see that just with your work in NSPR.
>
> If you're going to do it this way, *stop after NSPR*, review what you learned, look at what didn't work, and then decide if that's the
> way you want to tackle the whole project. Imagine ten little groups of people working on various bits. Once you start introducing
> dependencies, you're going to start seeing these problems, even if you don't see them now.
>
> And if you won't listen, nobody can help.
>
Once the NSPR is done then I agree we should review it and look at the
lessons learnt and improvements we can make. I am also trying to get
cross module API's tied down (such as the FE API) so that we can
eliminate as many cross module dependancies as possible.
I'm willing to listen to everyones view point, but it's the general
concensus that counts.
> > 3) Code review is done by the group (in the same way as most other free
> > software). Anyone can download the code and check over it, bringing up
> > issues as they arise.
>
> That's not the issue. The issue is one of project management, coding standards, and verification before checkin, rather than a
> "worksforme" attitude of checkin.
>
> > I hope this answers your questions.
>
> Hmm. I cannot and will not get involved in the port; I've got my hands tied with MozillaWorld and The Frontend I'm planning. So I'm
> not *really* asking questions; just trying to get you guys to think some of what you're doing through before diving in to an empty
> swimming pool. I can't say I like the way you guys are doing the work so far, and I hope that it doesn't continue along this path,
> because even if you're successful in your plans, at this rate, it won't have been a fun ride.
>
> :plur,
> Greg
>
You don't have to be involved in the project to bring up valid questions
:). You've put your concerns in a constructive way which will make
others think about them, I've answered them with how I feel, but if
other people see what you've written and think your right then I'd more
than welcome them speaking up so we can make a group decision.
Al.
Gregory R. Block
> I'm trying to apply the divide and conquer method of project management
> to the project in that we are splitting the tasks down and down into
> atomic sections (Mozilla splits into NSPR, FE, etc.. NSPR then splits
> into Threads, IO, etc.. IO splits into..... (you get the idea)).
>
> I understand that this may introduce some cross section inefficiencies,
> but if group B say "Hey, it would be better if we did x" (In the same
> way Kevin is talking about the change to the PLBase64 stuff) then we can
> iron those out. (find & grep will allow us to see where the call is used
> :)).
Okay, but that only works if the smaller groups actually do the project management. That's where things fall apart, and that's where I see
problems. Subgroups need to document their methods, dependencies, architectures, milestones, and goals. You, as the Pinnacle of Holiness,
must ensure that there are standards by which those things can be written, and demand that they be done.
Otherwise, it's like a giant ant. Ants are fascinating architectures, and work in small sizes, but by the time they reach It Came From The
Desert proportions, it's crushed under its own weight.
I'd hate to see "It Came From The JVM" as a follow-up movie. :)
> Agreed, which is why we have written the code so we can run JavaDoc over
> it and generate the technical docs. This coupled with the documentation
> for the main C/C++ source code tree (the design of we are trying to
> stick to as closely as possible) should allow most people to get up to
> speed quite quickly.
Notes: 1) The main C/C++ source tree documentation sucks. You really need to do better than that. 2) You don't talk about what happens
when all that main C/C++ source tree documentation no longer applies to your codebase because it has changed, either due to the integration
of Raptor, Mail/News, or what have you.
If you rely on Mozilla documentation, you're going to have to deal with the Mozilla tree diverging away from your own development at a rate
you can't keep up with: You can't code fresh *and* constantly make the changes that will happen to the Mozilla tree.
> As for documentation of decisions we always have the mozilla.org
> newsgroup archive to fall back on.
Dunno if you're seeing what I'm getting at, but that's like saying "I'll grab these five engineers, discuss the architecture, and if we end
up disagreeing later, I'll record the whole audio session and stamp it on a CD."
Discussion groups aren't good enough, in the long run. Without something set in concrete, for all to see, you're going to get bitten. IMO.
> Once the NSPR is done then I agree we should review it and look at the
> lessons learnt and improvements we can make. I am also trying to get
> cross module API's tied down (such as the FE API) so that we can
> eliminate as many cross module dependancies as possible.
>
> I'm willing to listen to everyones view point, but it's the general
> concensus that counts.
Yeah, but the problem with consensus is that everyone walks away from a consensus with a different idea of what the consensus was.
That's the point of documentation. :)
Also, tying down cross-module APIs, like the FE, is the perfect example of why you need to think about architecture before getting involved
in the coding, and having an architectural design that lets you not have to worry.
Personally, I develop object architectures before I touch code. I realise that it doesn't apply to all languages, but where possible, I
define regions and APIs. You've got some predefined ones, and in other places, you're working on defining them - but your first task should
be to lay it all out, not plug away at code.
Before or after NSPR doesn't matter, so long as the focus is small and tight, for now, I guess. But do it later, and don't put it off.
> You've put your concerns in a constructive way which will make
> others think about them, I've answered them with how I feel, but if
> other people see what you've written and think your right then I'd more
> than welcome them speaking up so we can make a group decision.
You've been doing consulting too long. ;)
:plur
Greg
Joshua E. Rodd
Stephen Fitch wrote:
> Lee Daniel Crocker wrote:
> > Phase 1 could only be done on Windows. That's regrettable, and is
> > indeed
> > a downside of my approach. But if that's the only approach that's
> > actually
Many of us don't even have Windows toolkits (J) on our computers.
> > _doable_ in a reasonable time, sometimes you have to compromise on
> > politics
> > for technical feasibility. And the end result is the same: a 100% pure
> > Java product.
Yes, but you shut out half the developers!
> Steering clear of the Phase 1 choices for dev tools etc, it would be
> good if we could maintain the cross platform nature of anything deliverd
> from this project. Even if in the first instance that Windows 95 stuff
> has to be used to bootstrap the whole process, because of the widespread
> infestation of it, even to me it seems the logical basic building platform.
I thought Java would run on any platform. Why do operating systems even
need to be mentioned?
I hope no-one is proposing using a Java toolkit like Visual Cafe or the
like. That would hurt us developer's who can't buy expensive toolkits.
> I'd be interested to here from anyone else with a Solaris or UNIX underlying
> platform so that we can start to build ideas as to how to get the results of
> the efforts on to the multiple platforms that I hope we would all like to
> see it run.
I, for one, need OS/2 support.
> Those interested in quality testing the cross platform delivery on Solaris can
> drop me a line, I expect I might be able to cover both the SPARC and x86
> platforms.
> Some I suggest might also wan't to co-ordinate the MAC and other platforms.
I'd like to the OS/2 support, especially seeing I'm the only OS/2 users
in this
newsgroup.
> The whole idea of this project it would seem to me would be to
> create a cross platform result, but with quality on each. That
> takes effort.
Yes!
Cheers,
Kevin Kelley
[ahh, napalm in the morning]
Laurent Thérond
In article <353F6CAE...@netscape.com>, gbl...@netscape.com says...
> 2) Make a very solid architectural analysis before you do any major development
> work, because the cost of recoding will be painful, and you're going to do it *a
> lot* if you spend your time following the C interfaces around.
>
>
Everyone is ready to say that, but only Giao expressed his vote towards a
CASE tool that would allow us to set this "very solid architectural
analysis."
I guess time spent fighting "religious" positions is more important...
Oliver White
I even have a maintentance plan for the FAQ! How's that for
documentation!
1) Make sure Al tells me when he changes structure of his web site.
2) List all links.
3) Test links once per week :)
On 25 Apr 98 11:10:06 GMT, a...@alsutton.com (Al Sutton) wrote:
>This is a cryptographically signed message in MIME format.
>
>--------------ms43EB111BA795B2B15B801D8F
>Content-Type: multipart/mixed; boundary="------------0A276B09776DCAD5CD7CD470"
>
>This is a multi-part message in MIME format.
>--------------0A276B09776DCAD5CD7CD470
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Gregory R. Block wrote:
>>
>> Al Sutton wrote:
>>
>> > I'm trying to apply the divide and conquer method of project management
>> > to the project in that we are splitting the tasks down and down into
>> > atomic sections (Mozilla splits into NSPR, FE, etc.. NSPR then splits
>> > into Threads, IO, etc.. IO splits into..... (you get the idea)).
>> >
>> > I understand that this may introduce some cross section inefficiencies,
>> > but if group B say "Hey, it would be better if we did x" (In the same
>> > way Kevin is talking about the change to the PLBase64 stuff) then we can
>> > iron those out. (find & grep will allow us to see where the call is used
>> > :)).
>>
>> Okay, but that only works if the smaller groups actually do the project management. That's where things fall apart, and that's where I see
>> problems. Subgroups need to document their methods, dependencies, architectures, milestones, and goals. You, as the Pinnacle of Holiness,
>> must ensure that there are standards by which those things can be written, and demand that they be done.
>>
>> Otherwise, it's like a giant ant. Ants are fascinating architectures, and work in small sizes, but by the time they reach It Came From The
>> Desert proportions, it's crushed under its own weight.
>>
>> I'd hate to see "It Came From The JVM" as a follow-up movie. :)
>>
>
>Understood, which is why I'm trying to get people to sort out the API's
>and tell the list (e.g. the FE API). Javadoc should help us a lot in
>that it will generate a lot of the methods available, and if a group has
>a dependancy they should tell the rest of the group. Javadoc will also
>help with the object structure, but actual program flow information will
>have to be given by the groups (it should follow the flow of the mozilla
>code, but the docs for that are pretty much non exsistant).
>
>Milestones and goals are quite easy to deal with, I'm not setting any
>milstones so that people can do what they can when they can and aren't
>pressured into coding. Goals, well, the goal is to get classes for the
>rest of the group to use :).
>
>I'd hate to see 1001 classes that have altered the documented API's in a
>minor way which results in an integration nightmare.
>
>
>> > Agreed, which is why we have written the code so we can run JavaDoc over
>> > it and generate the technical docs. This coupled with the documentation
>> > for the main C/C++ source code tree (the design of we are trying to
>> > stick to as closely as possible) should allow most people to get up to
>> > speed quite quickly.
>>
>> Notes: 1) The main C/C++ source tree documentation sucks. You really need to do better than that. 2) You don't talk about what happens
>> when all that main C/C++ source tree documentation no longer applies to your codebase because it has changed, either due to the integration
>> of Raptor, Mail/News, or what have you.
>>
>
>I'm trying to keep the group as close to the C/C++ code for the initial
>implementation. If we deviate from the documents then we can create
>addendum's to note this.
>
>
>> If you rely on Mozilla documentation, you're going to have to deal with the Mozilla tree diverging away from your own development at a rate
>> you can't keep up with: You can't code fresh *and* constantly make the changes that will happen to the Mozilla tree.
>>
>
>Understood. Hopefully there will be a list of mods to the main tree
>which we can follow (in order) and so keep track with the code even
>though we may be a few weeks/months behind the current C/C++ version.
>
>> > As for documentation of decisions we always have the mozilla.org
>> > newsgroup archive to fall back on.
>>
>> Dunno if you're seeing what I'm getting at, but that's like saying "I'll grab these five engineers, discuss the architecture, and if we end
>> up disagreeing later, I'll record the whole audio session and stamp it on a CD."
>>
>> Discussion groups aren't good enough, in the long run. Without something set in concrete, for all to see, you're going to get bitten. IMO.
>>
>
>True, but if we use the newsgroup list as our concrete slab then once a
>decision is made we can point people at that.
>
>
>> > Once the NSPR is done then I agree we should review it and look at the
>> > lessons learnt and improvements we can make. I am also trying to get
>> > cross module API's tied down (such as the FE API) so that we can
>> > eliminate as many cross module dependancies as possible.
>> >
>> > I'm willing to listen to everyones view point, but it's the general
>> > concensus that counts.
>>
>> Yeah, but the problem with consensus is that everyone walks away from a consensus with a different idea of what the consensus was.
>>
>> That's the point of documentation. :)
>>
>
>Agreed, but hopefully the list will throw up any misunderstandings.
>
>> Also, tying down cross-module APIs, like the FE, is the perfect example of why you need to think about architecture before getting involved
>> in the coding, and having an architectural design that lets you not have to worry.
>>
>
>Again agreed, Giao take note :).
>
>> Personally, I develop object architectures before I touch code. I realise that it doesn't apply to all languages, but where possible, I
>> define regions and APIs. You've got some predefined ones, and in other places, you're working on defining them - but your first task should
>> be to lay it all out, not plug away at code.
>>
>
>I have taken the NSPR docs and code as the design documentation, what
>the NSPR people are plugging away at is implementing that design in
>Java.
>
>> Before or after NSPR doesn't matter, so long as the focus is small and tight, for now, I guess. But do it later, and don't put it off.
>>
>
>
>Agreed... Everyone note (This one will be carved in the concrete slab of
>the newsgroup) we will document the beast!!!
>
>
>> > You've put your concerns in a constructive way which will make
>> > others think about them, I've answered them with how I feel, but if
>> > other people see what you've written and think your right then I'd more
>> > than welcome them speaking up so we can make a group decision.
>>
>> You've been doing consulting too long. ;)
>>
>
>I know... next post I'll be talking about synergies.
>
>> :plur
>> Greg
>>
>
>Al.
>
>--
>Al Sutton
>(a...@alsutton.com)
>
>The views expressed are solely mine and not those of any company
>or organization with which I may be associated.
>
>All Junk/Bulk E-mail sent to any address in the alsutton.com
>domain will result in the sender being charged 1,000 pounds sterling.
>--------------0A276B09776DCAD5CD7CD470
>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for Al Sutton
>Content-Disposition: attachment; filename="vcard.vcf"
>
>begin: vcard
>fn: Al Sutton
>n: Sutton;Al
>org: alsutton.com
>adr: ;;;London;;;UK
>email;internet: a...@alsutton.com
>title: Consultant
>note;quoted-printable:Network Security, Mobile Network Deployment,=0D=0A=
> Network Infrastructure (Design and Implementation), =
> =0D=0A=
> C/C++/Java Software Development
>x-mozilla-cpt: ;0
>x-mozilla-html: FALSE
>version: 2.1
>end: vcard
>
>
>--------------0A276B09776DCAD5CD7CD470--
>
>--------------ms43EB111BA795B2B15B801D8F
>Content-Type: application/x-pkcs7-signature; name="smime.p7s"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment; filename="smime.p7s"
>Content-Description: S/MIME Cryptographic Signature
>
>MIIQlwYJKoZIhvcNAQcCoIIQiDCCEIQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
>DwUwggpLMIIJtKADAgECAhB2yMKZuu0Y8zYZoIJ1FGADMA0GCSqGSIb3DQEBBAUAMGIxETAP
>BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy
>aVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA2MTUwMDAw
>MDBaFw05ODA2MTUyMzU5NTlaMIIBEzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl
>cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVh
>bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT
>IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MTMwMQYDVQQLEypEaWdpdGFsIElEIENs
>YXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEjAQBgNVBAMTCUFsIFN1dHRvbjEeMBwG
>CSqGSIb3DQEJARYPYWxAYWxzdXR0b24uY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMu9
>Lfh8bq/s6bJq6LN8D7wtpKDGtd7Z9Td8xTQzzWN8AoCZCGwouBS2v2QyGtRGAAqncX7fhkWf
>dxAaikP2CckCAwEAAaOCB5EwggeNMAkGA1UdEwQCMAAwggIfBgNVHQMEggIWMIICEjCCAg4w
>ggIKBgtghkgBhvhFAQcBATCCAfkWggGnVGhpcyBjZXJ0aWZpY2F0ZSBpbmNvcnBvcmF0ZXMg
>YnkgcmVmZXJlbmNlLCBhbmQgaXRzIHVzZSBpcyBzdHJpY3RseSBzdWJqZWN0IHRvLCB0aGUg
>VmVyaVNpZ24gQ2VydGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQgKENQUyksIGF2YWls
>YWJsZSBhdDogaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzsgYnkgRS1tYWlsIGF0IENQ
>Uy1yZXF1ZXN0c0B2ZXJpc2lnbi5jb207IG9yIGJ5IG1haWwgYXQgVmVyaVNpZ24sIEluYy4s
>IDI1OTMgQ29hc3QgQXZlLiwgTW91bnRhaW4gVmlldywgQ0EgOTQwNDMgVVNBIFRlbC4gKzEg
>KDQxNSkgOTYxLTg4MzAgQ29weXJpZ2h0IChjKSAxOTk2IFZlcmlTaWduLCBJbmMuICBBbGwg
>UmlnaHRzIFJlc2VydmVkLiBDRVJUQUlOIFdBUlJBTlRJRVMgRElTQ0xBSU1FRCBhbmQgTElB
>QklMSVRZIExJTUlURUQuoA4GDGCGSAGG+EUBBwEBAaEOBgxghkgBhvhFAQcBAQIwLDAqFiho
>dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgMBEGCWCGSAGG+EIBAQQE
>AwIHgDA2BglghkgBhvhCAQgEKRYnaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
>cnkvQ1BTMIIEhwYJYIZIAYb4QgENBIIEeBaCBHRDQVVUSU9OOiBUaGUgQ29tbW9uIE5hbWUg
>aW4gdGhpcyBDbGFzcyAxIERpZ2l0YWwgCklEIGlzIG5vdCBhdXRoZW50aWNhdGVkIGJ5IFZl
>cmlTaWduLiBJdCBtYXkgYmUgdGhlCmhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4g
>VmVyaVNpZ24gZG9lcyBhdXRoLQplbnRpY2F0ZSB0aGUgZS1tYWlsIGFkZHJlc3Mgb2YgdGhl
>IGhvbGRlci4KClRoaXMgY2VydGlmaWNhdGUgaW5jb3Jwb3JhdGVzIGJ5IHJlZmVyZW5jZSwg
>YW5kIAppdHMgdXNlIGlzIHN0cmljdGx5IHN1YmplY3QgdG8sIHRoZSBWZXJpU2lnbiAKQ2Vy
>dGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQgKENQUyksIGF2YWlsYWJsZQppbiB0aGUg
>VmVyaVNpZ24gcmVwb3NpdG9yeSBhdDogCmh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbTsgYnkg
>RS1tYWlsIGF0CkNQUy1yZXF1ZXN0c0B2ZXJpc2lnbi5jb207IG9yIGJ5IG1haWwgYXQgVmVy
>aVNpZ24sCkluYy4sIDI1OTMgQ29hc3QgQXZlLiwgTW91bnRhaW4gVmlldywgQ0EgOTQwNDMg
>VVNBCgpDb3B5cmlnaHQgKGMpMTk5NiBWZXJpU2lnbiwgSW5jLiAgQWxsIFJpZ2h0cyAKUmVz
>ZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVEIEFORCAKTElBQklMSVRZIExJ
>TUlURUQuCgpXQVJOSU5HOiBUSEUgVVNFIE9GIFRISVMgQ0VSVElGSUNBVEUgSVMgU1RSSUNU
>TFkKU1VCSkVDVCBUTyBUSEUgVkVSSVNJR04gQ0VSVElGSUNBVElPTiBQUkFDVElDRQpTVEFU
>RU1FTlQuICBUSEUgSVNTVUlORyBBVVRIT1JJVFkgRElTQ0xBSU1TIENFUlRBSU4KSU1QTElF
>RCBBTkQgRVhQUkVTUyBXQVJSQU5USUVTLCBJTkNMVURJTkcgV0FSUkFOVElFUwpPRiBNRVJD
>SEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSClBVUlBPU0UsIEFORCBX
>SUxMIE5PVCBCRSBMSUFCTEUgRk9SIENPTlNFUVVFTlRJQUwsClBVTklUSVZFLCBBTkQgQ0VS
>VEFJTiBPVEhFUiBEQU1BR0VTLiBTRUUgVEhFIENQUwpGT1IgREVUQUlMUy4KCkNvbnRlbnRz
>IG9mIHRoZSBWZXJpU2lnbiByZWdpc3RlcmVkCm5vbnZlcmlmaWVkU3ViamVjdEF0dHJpYnV0
>ZXMgZXh0ZW5zaW9uIHZhbHVlIHNoYWxsIApub3QgYmUgY29uc2lkZXJlZCBhcyBhY2N1cmF0
>ZSBpbmZvcm1hdGlvbiB2YWxpZGF0ZWQgCmJ5IHRoZSBJQS4wgYYGCmCGSAGG+EUBBgMEeBZ2
>ZDQ2NTJiZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0
>YmM5NzAxNzQ3ZGE1YzFlMzE0MWJlYWRiMmJkMjhkODMxMmJkNjI5OGE2MTE0OTlkYTFiZTQz
>ZjRlNDkyNjU0MTANBgkqhkiG9w0BAQQFAAOBgQAGQE8tbwmbdIYHexKBbcneS9HJKUEVFOZt
>wYDcX6EekBGQGd3knTowhY5CU+SqtxeNQ8NZMwDG+n8u7fLq2rcv3T5XUn1C3z77VLlXpks9
>/SHWoSzllkeEgpk3NS0f+p0uAU+zCpHvxbFcxcEAbPS6YuAZxCcg9IR/DKlTRFtCbzCCAn0w
>ggHmoAMCAQICFHUTa1jzgGlXdaaiTVkQTZzqdkrxMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV
>BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs
>aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NzA2MjQwNzAwMDBaFw05
>OTA2MjQwNzAwMDBaMGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwg
>SW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2Ny
>aWJlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAthSmz03QBQ3YyiPQb6q0KZJjjiz4
>b5bXLp12SxGxNo1XycP9HMa6/h4IujPKleq+41vNBqi3eR1EKu1z8rFSg2gQcGSR1z5r+fdd
>nRRDm26XRZiBR9Ety927ctdMP3Gq4kDyVDm8Fu7PfOy62z9sKrMWsYYSna6TNNW41dD3PqkC
>AwEAAaMzMDEwEQYJYIZIAYb4QgEBBAQDAgEGMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
>AgEGMA0GCSqGSIb3DQEBAgUAA4GBAJIMS+m6k83/2uZg/Z5kA2YVL1Y8OExoSkfF86uPJdlm
>Q3NDFXNEvhRIgVp3DMx66tmxvPKL/xGx3xRQSNxlHQuJ+aFeSFJv7bVr9LgITDjwuYlnKQ/g
>4Df3puvU9NVCqV39veeefBvnT4UtBKFgLoW46+L67xQFJhUYVW8ToR1xMIICMTCCAZoCBQKk
>AAABMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg
>SW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1
>dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw05OTEyMzEyMzU5NTlaMF8xCzAJBgNVBAYTAlVT
>MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJp
>bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
>gYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea
>BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7Nslj
>XMXg1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBSc7qaVdzc
>P4J9sJCYYiqCTHYAbiU91cIJcFcBDA93Hxih+xxgDqB1O0khQf6nXC1MQknT/yjYjOqd/skH
>4neCUyPeVfPORJP6+ky9yjbzW2aynsjyDF5e1KG0IQkzyjtZ/JLCOPyt2ZYk4C36oyn1M2h4
>TrS8n2k14qiYlHM7xDGCAVowggFWAgEBMHYwYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNV
>BAoTDlZlcmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5k
>aXZpZHVhbCBTdWJzY3JpYmVyAhB2yMKZuu0Y8zYZoIJ1FGADMAkGBSsOAwIaBQCgfTAYBgkq
>hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw05ODA0MjUxMTEwMDZaMB4G
>CSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFPxtSox0Ylkk
>HZwlLFRKmlKrL+r3MA0GCSqGSIb3DQEBAQUABECo3j+VwPfjJRxy0JRwVz2lZLK4A0rXvB3a
>eaKCMmJSEZo+h0KUgRi7LJWVCSJ/uLVY8dbDAz7hsLi7WXxYADeg
>--------------ms43EB111BA795B2B15B801D8F--
>
>
>
>