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? _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
