On Sep 6, 12:10 am, Jason Orendorff <[EMAIL PROTECTED]> wrote: > It seems to me our choices are: > 1) don't try to support multiple language bindings > 2) support them in a common way, with common > library code, in a form that might solve > problems for other people too (and thus attract > contributors) > 3) support them as we do PyXPCOM and > LiveConnect now, i.e. by ourselves, separately, > and not especially well > > I consider #1 a strong option. #2 is pretty nutty. I brought it up > for two reasons. First, #3 is a lot like #2, only without pooling any > effort or designing for pluggability. Under #3, lesser-used languages > (like Python) are unavoidably second-class citizens. They'll never > reflect XPCOM with high fidelity unless someone spends an unlikely > amount of effort on it. My impression is that PyXPCOM is already > lagging and unlikely to catch up, much less keep pace with coming > changes.
I think it would be a step backwards for the platform to drop external languages. Many people who adopt the platform choose to use Python for valid reasons - such projects include ActiveState's Komodo and the OLPC project. In both cases, the ability to use Python was crucial to the choice to use the platform - indeed, in ActiveState's case, they felt so strongly about using Python that they funded the creation of PyXPCOM. Still today, for any non-trivial code they still use Python, even if that means writing a little "shim" in Javascript to enable that. Also, pyxpcom is not lagging from an xpcom POV. xpcom itself is not undergoing many changes, so it is keeping up fine. What is *not* happening is decent integration into the non XPCOM world. Alot of the DOM, for example, is exposed in a way that is JS specific. Work to integrate JS and other languages so, for example, 'expando' objects can be accessed in different languages is lagging. Python does *not* have access to parts of the platform that have been de-comtaminated, or implemented using anything other than xpcom. So I would argue that it is not pyxpcom that is lagging, but instead the platform itself is trying to steam away from xpcom, and in the process also steaming away from the integration opportunities xpcom has already demonstrated. I understand xpcom has a number of issues, but I fear that some of the proposed solutions risk throwing out the baby with the bath water. As you are, I'm also slightly skeptical that "insisting" that languages which want to play in our new playground be reimplemented on a new virtual machine will be fruitful. Even if such an implementation of Python was trivial to put together, I don't believe it would keep those existing Python based projects happy. People choose to use Python inside the mozilla architecture both for the language, and for the library. In the same way that any non-trivial Python program can't run the same on CPython and IronPython (ie, the .NET port), it will not be a simple matter of swapping out the language implementation and still expecting existing Python code to run. > I'm not convinced we want multi-language support. It's real expensive > and not very useful. I think that we should try and remember why we wanted to open up the existing architecture to external languages in the first place, and see if those reasons are still valid. I can't see why they are not, but if we really do want to scale back the scope of this as a general purpose "application platform", then I agree it would make our lives much easier. But is this really all about making our lives easy? ;) Cheers, Mark _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
