(bcc'ing a couple of people, mark and ian, because pyjamasdev doesn't cope with cc)
On Fri, Mar 2, 2012 at 3:57 AM, Jeffrey Van Voorst <[email protected]> wrote: > To be more clear, I am not wondering about the direction of Mozilla's > code base and future directions as a goal, but rather about the amount > of work involved. surprisingly little, because the code does actually work. the problem is that the mozilla core team simply are not aware of that. they don't believe that their own technology is even capable of the uses to which it's been put. when i say surprisingly little, it's because it's a maintenance task, not a development task. but because the mozilla core team haven't seen pyjamas-desktop in action, they simply don't believe that. you can see evidence of this in ben's responses. he doesn't understand that hulahop is a mature - completed and actively-used project - that requires *no* development. > I know enough about python to C/C++ language binding to be dangerous > via boost::python. To me the two advantages of using boost::python > over other methods is not having to handle reference counting (unless > one is invoking some voodoo), and if it compiles it just works (unless > I messed up on managing the memory in my own code ...). I am not > suggesting that boost::python is even a relevant tool for xulrunner > bindings (or whatever you want to call the translation between the DOM > and python), but I am wondering why it has to be so difficult. I > understand requiring reference counts in C, but such details should be > hidden from javascript or any other "higher" language. precisely. you're a python programmer. i've pointed this out in the discussion. mark, ian: python programmers are not c or c++ or java programmers. they picked python precisely so that they don't have to get involved with refcounting etc. etc. or static interfaces. as such, they're simply not equipped to deal with this stuff. we have an entire community that is counting on the mozilla foundation for one of its "modes of operation", and nowhere within that community is there the technical resources to sort out the mess caused by the apathy and ambivalence of the mozilla foundation towards code that ALREADY WORKS and is only _not_ working because of lack of maintenance of the functions that that STABLE code uses. l.
