<luke.leighton@gmail.com>:
Hello,
I believe the the guy who is pushing netsurf the most, is currently
on Vacation(?), and so maybe it would be good if we wait for what
John Mark Bell will say about it.
>* _then_ things like language bindings can be added.
>* the language bindings themselves technically have been mulled over
>and as i understand it you have been thinking of implementing them in
>one of two ways:
> a) a code auto-generator which will generate a one-for-one
>function/property mapping from language X to DOM function/property X.
> b) a dynamic runtime "middleware" jobbie which uses a binary
>encoding (type library) to represent the DOM's functions/properties.
>* i mentioned the pros and cons of each of a) and b).
> a) will easily turn a 400k netsurf executable into a 5400k netsurf
>executable due to the overwhelming size of the HTML5 / DOM
>specification: 350 DOM objects, 2,000 functions within those objects
>and over 20,000 properties in those objects.
> b) will be slightly slower, requiring a runtime overhead to decode
>the "type library" but the code size will be massively reduced.
> (observation: potentially, the reduction in code size could well
>result in increased speed on slower CPUs especially embedded low-end
>processors with smaller or zero sized caches. bottom line: it's not
>clear-cut!)
I still don't get why you want to have such an component model. I'm
not saying that I know enough about it, but anyway - there's always
another way. You talk like there is no alternative. But on the other
extreme, there can be one single dispatcher function to access ALL
DOM properties. That would mean you have to Implement on interface
to ONE C function. That doesn't sound evil to me.
Also, it sounds to me, like you do not keep in mind that:
- NetSurf is C, not C++
- Other Languages can call C functions, why should netsurf
be SUPER-NICE and offer the posssibility for other Languages
to call DOM stuff? Especially Python has an nice interface to C,
AFAIK.
- For my system, there exists no clean way for Shared Libs,
everything is linked statically, sometimes I'm thinking
that your approach may thinks that shared libs are available
everywhere.
- When linked statically, type safety is ensured by C, at least
when you prototyped everything fine. I believe that's also the
case for shared lib's - so I still see no reason for an COM.
( + the Components still need to stick to CDECL rules anyway )
> b.iii) GObject with Introspection. this one is interesting, because
>it turns out that gobject-introspection now has *multiple* language
>support... including *two* separate javascript bindings! in other
>words if you were to adopt gobject as the netsurf middleware, should
>you choose this route, you'd *automatically* get javascript
>bindings... *for free*... as well as several other programming
>languages.
> this is why middleware is so powerful - as you no doubt, as free
>software programming experts, already know. but please bear with me:
>i am writing to a wider audience with the above, so for *their*
>benefit it has to be spelled out.
Sorry, I still don't get why it is so powerfull, + I don't get how it
is related to JavaScript within NetSurf.
Please be patient with me ;)
1. We need a wrapper to javascript engines, at least I think that's
nice to have. So people can compile with the JavaScript
implementation
available to their system ( my system is limited to spidermonkey,
maybe KDE-js ).
2. We need a glue to implement DOM objects within JavaScript.
( your glue is named COM, right? I do not mean COM in Microsoft
slang,
but an Component Object Model in general )
3. The glue routes function calls from javascript to libdom and vice
versa,
which will trigger events (right?).
4. I still do not see the need for COM. Please tell me why and why it
is so
important.
5. The glue must be C, because it must be fast. Optional glue is not
my wish, but if someone wants to replace the C glue with somethin
like python, I guess that's still possible, no need for
COM.
Do you have a graphic which shows with on single look, why COM is so
important? :)
Greets,
m
No comments:
Post a Comment