On Fri, Mar 2, 2012 at 1:52 PM, Jeffrey Van Voorst
<[email protected]> wrote:
> I am not going to pretend to understand what people such as Ben and
> Bobby are thinking (they appear to be confusing the difficulty of
> javascript bindings versus lazy python bindings).

 i... don't think so.... mmm... ok i would be surprised if that was
true.  javascript bindings also have to be lazy bindings (lookup by
name) because, well... you don't put
document.QueryInterface("0101230-3012301-2301231-03120312") into a web
page, do you?? you don't go looking up the UUID of the IDL file, do
you?  you just do document.getElementsByTagName.

 and behind the scenes, this magic function called IDispatch is
called, which can do translation of names (getElementsByTagName) into
UUIDs (0101230-3012301.......) for you.

 so in that regard, javascript and python are in exactly the same boat.

 but for c, c++ and java, it's considered "lame" to use IDispatch.  so
you use the UUID in order to get that speed, speed, speed feeling.

 ok that's probably a bit garbled, but you get the idea.


>  However, I am
> inferring from their replies that they never had and still don't want
> anything to do with pyxpcom (see
> https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion),
> and the responsibility of pyxpcom is entirely in the hands of the
> pyxpcom maintainers.

 yes.  and that's the problem.  ok, more specifically: it's this
"rushing ahead with decisions and code changes without waiting to
check if everything's ok for pyxpcom and hulahop" that's not ok.

 it means that each release is effectively saying "fuck you - if it
doesn't work, tough shit: go fuck yourself.  we don't care".

 which is in direct contravention of the mozilla mission statement.

 whoops.


> Although that may be sufficient for pyxpcom, given the notes above, we
> still have the issue regarding Hulahop.  This somewhat confuses me as
> a google search for hulahop brings me to an OLPC wiki that defines
> hulahop as "HulaHop is Gecko 1.9 (Firefox 3.0 core) web browser as a
> simple embeddable control with Python DOM access. It is a PyGTK Widget
> that you can use in your application to embed a web browser."
> Therefore is the issue the unwillingness to support hulahop or its
> successor in newer versions of the Firefox core code or an
> unwillingness to support pyxpcom or both?

 both.

 as you progress through the discussions, there, you'll soon come to
ben's responses, in which he begins to outline how he misunderstands
the fundamental principles behind why hulahop actually works.

 also you'll see that he assumes that hulahop doesn't actually work!

 he also assumes that there is a need for multi-threading in pyjamas
applications (which there isn't), and as he doesn't know about the
hulahop.startup function, which sets up the gecko cache / profile
directory, he assumes that there's work needed there _too_.

 so it's a massive set of dissilusionment, misunderstandings,
technical ignorance of the workings of their *own* code, lack of
understanding of the uses to which their *own* technology is being
put...

 i'm just... blown away, and really really frustrated by the whole
thing.  i can understand if new people aren't familiar with how their
code's being used, but for people who've been involved with it for a
decade??

 you see what i'm up against, here?

l.

Reply via email to