Trane Francks wrote:
On 5/15/14 4:31 AM +0900, Rufus wrote:
MCBastos wrote:
Interviewed by CNN on 14/05/2014 16:05, Rufus told the world:
...personally, I don't think SM is all that "complex"...it's not
like it
does 3D graphic presentations with interactive panning and rotation or
anything math-intensive like that.
Actually, math stuff is CPU-intensive but not necessarily intrinsically
complex (although optimizations might add to it).
Depends on what you're doing I guess...I evaluate and disposition
quasi-realtime system software for a living...SM is pretty simple WRT to
what I work with. I don't see SM doing anything that interdependent,
system-wise.
Working with externally-generated data, OTOH, is VERY complex, because
you have to deal with all the novel and creative ways people find to
*fuck up*.
SM is basically a front-end to a database...no hit against SM if people
generating the data that go into it screw up their data, but SM should
do what it does consistently and as error free with respect to it's
platform interface as a user would expect - and I see problems going
unaddressed in that regard, at least for Mac OS X. Platform interface
requirements are pretty stable, generally speaking.
The biggest issue with regard to complexity is the sheer number of RFCs
that the code must correctly support. RFCs describe the behaviour, but
not the implementation. If you've ever coded anything bigger than, say,
5,000 lines of code in a single program, you soon get a grasp of how
quickly interdependencies can greatly complicate maintenance.
...LOTS bigger. We have a web-based tool at work that is a *real*
mess...and that's been an excuse for not fixing it even though we live
in a nest of professional coders...for over a decade.
So I have *zero* sympathy. Fix the code.
Non-compliant HTML is just the tip of the iceberg. Then you have all the
Javascript attacks. And let's not forget that Seamonkey is also a mail
client... I remember seeing a whole series of blog postings explaining
why email is a difficult animal to tame... where is it... oh yes, here:
http://quetzalcoatal.blogspot.com.br/search/label/email-hard
I don't see non-compliant HTML as SM's problem really...and besides,
Of course, it's SM's problem. Poorly or intentionally malcrafted input
can cause segfaults and escalated privileges. SeaMonkey has the arduous
task of taking whatever comes in and hopefully displaying it in a manner
that pleases the end user, all while (hopefully) sanitizing the input
such that it doesn't cause failures. Because of the sheer
unpredictability of the input stream, input handling is a big, big
domain. The rendering engine spends a huge amount of its time evaluating
the sanity of the HTML being fed into it.
Again, as a user I don't care how SM does that - but I do care how and
that it does what *I* tell it to do...the "fixes I can see". I don't
see enough of them.
Most of my complaints with SM are UE oriented...UE issues should be far
easier to fix, and so I wonder why they always get pushed to the back
burner for the sake of sheer "techiness" and the "hard stuff".
that's isn't really an issue I see or take any notice of as a *user* -
what I want fixed are UE/operation related problems...like getting
randomly prompted for my Master Password and trashing my Download and
session, or being told to stop using the Profile Manager to "solve" a
problem...or the short drawn drops which finally got fixed. As a user
those are the sorts of things I can *see*, and what I can *see* matters
more to me as a user.
The problem with the profile manager startup bug is that it's been 2
years. Finding the original regression will be difficult. Good luck
finding a developer who'll want to explore that realm. (And such is the
downside of community-driven development.)
The biggest problem I infer with the Profile Manager is that it seems to
have *two* branches as evidenced by the differing splash screens when
invoked - the more modern one at start up, and the older one when
invoked from within the Browser...so no wonder the left hand doesn't
know what the right hand has done...why isn't this code shared and there
is only *one* way to draw the splash? Could the whole of the code for
the PM duplicated? And what does the PM have to do why I can't get SM
to launch the correct target via an OS X Alias?
These are the sort of questions that make me doubt the whole approach,
and how the whole of the project code is or isn't
managed/integrated...it just seems sloppy, and a pathway to building
bugs in vise out.
--
- Rufus
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
