Re: [Edbrowse-dev] Javascript support

[Adam Thompson <arthompson1990@gmail.com>]

Hi Karl,

On Sun, Dec 22, 2013 at 05:26:49PM -0500, Karl Dahlke wrote:
> It seems to me you are spot on,
> assumingf we want to take a few expedient steps,
> rather than a complete rewrite.
> When I think about string operations a complete rewrite is really tempting,
> but I know that would take to long.
> Our friend over at debian is tapping his foot.

Also, nice as string objects look, I've got a feeling that starting a rewrite
in this direction is going to be a lot more complicated to do right than we're
currently thinking.

> At this point I have to pat myself on the back, at least a little,
> since my design is based on encapsulation.
> I built jsdom.c and jsloc.c as a layer between edbrowse and the js engine,
> so that only these files need be touched.
> The rest of edbrowse knows nothing about javascript.
> So that's a couple thousand lines of code, not prohibitive.

That was how I thought things worked, well done for designing things this way.

> In fact, my original eb.h did not reference jsapi.h or anything javascript at all.
> I used void * for blind pointers to pass around js related structures.
> So an edbrowse buffer or context structure would contain a member
> void *js
> for all its javascript stuff, without knowing or caring what it meant.
> The semantics were all in js*.c.
> But at some point, and I don't remember when or why,
> 
> #include <jsapi.h>
> 
> was moved out of js*.c and into eb.h, so everyone could see
> and possibly muck with the javascript api.
> But still I don't think they do, not for the most part.
> It just means we can refer to jscontext * instead of void *,
> and the code is more readable,
> yet still I think it is all encapsulated in js*.c.

Ah ok.

> 
> The quick way, if there is such a thing,
> is to
> cp jsdom.c jsdom.C
> cp jslod.c jsloc.C
> Making the endings capital C instead of small c.
> Then call the c++ functions instead of the original functions.
> We can do this before the upgrade, since moz185 has the c++ interface.
> The new calls will likely return a pointer to an object, not a structure,
> but object structure it's all the same.
> I can't pass that around amonst the other c functions in edbrowse.
> In other words, go back to void * as it was before.

Agreed, though I'd probably use cpp as the file suffix and provide a js.h to
isolate datatypes etc, which could then be included in eb.h perhaps.
Also, this'd allow us to have a js * instead of a void * which pointed to all
the js machinary (runtime, context etc).

> Keep all the js headers and classes in js*.C, as it was before.
> Then when you can compile
> cc -c js*.C   (that's capital C)
> switch the Makefile over to use those files
> and not the original js*.c, which we'll keep around for a while
> until we know what we're doing.

I'm not sure if we can do this without the upgrade though as I've got a feeling
that they've slightly changed datatypes etc between versions.

> 
> So the first step might be to see if we canpt put
> 
> #include <jsapi.h>
> 
> back into jsdom.c and jsloc.c, and out of eb.h as it once was.
> Then make files with capital C instead of small c.
> gcc does the right thing based on the suffix.

Agreed with the exception of the file suffix.

> Then access the new api, which is probably not radically different
> from the old just creates objects and calls object methods instead of functions.

I don't think it's too different, it's still sort of a C api,
but now uses c++ stuff in the headers and underlying interface.

> I might be oversimplifying this terribly, I really don't know.
> I have bookmarked the documentation for all the smjs functions,
> is this updated to reflect the new c++ interface?

What urls have you got for them?

> And finally the question is who has time for all this?
> I don't know but I hope someone does,
> edbrowse is too valuable to die on the vine.

Agreed.

> I might, depending on how my life goes,
> but the first thing I have to do is learn c++,
> which I have religiously avoided for 30 years.
> Truly, for 30 years.

I can understand that.  If it wasn't for the fact that I needed to learn c++ as
part of my university course (we were exposed to it in my 1st and 2nd years and I need
it as one of the libraries I need for my masters project only provides a c++ api)
I'd also have avoided it.

> Maybe it's time.

Perhaps, but I'd rather not get into the object oriented programming discussion here.

> But if any of you know c++ better than me, which wouldn't be hard to do,
> then you're a step ahead.

I can have a go at making some of this work, but as I said,
I'm currently in my final year of a university course so there's a possibility
that my time may become seriously limited.

Cheers,
Adam.
PS: what's the usual procedure for submitting patches?