[Release 31] C API

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[Release 31] C API

olteanu.vasilica.claudiu
Hi there!

I would like to know if there are any chances to revert the C API for JSAPI in the new release or in the future.
I am implementing a PostgreSQL support for the libjssql extension [1] which currently uses the C API from JSAPI and I would like to know if I should port the current functionality to C++.

Also it would be very helpful if you could tell me about your plans with the new release. Will you make important changes which I should take into account? (like the one in version 24 - removing the C)

Happy hacking!
Claudiu
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Bobby Holley-2
On Thu, Mar 27, 2014 at 9:56 AM, <[hidden email]> wrote:

> Hi there!
>

Hi!


> I would like to know if there are any chances to revert the C API for
> JSAPI in the new release or in the future.
>

The chances of this are basically nil. It's near-impossible to properly
interface with a moving garbage collector without RAII helpers, which C
doesn't have. :-(


> I am implementing a PostgreSQL support for the libjssql extension [1]
> which currently uses the C API from JSAPI and I would like to know if I
> should port the current functionality to C++.
>

You should port to C++.


> Also it would be very helpful if you could tell me about your plans with
> the new release. Will you make important changes which I should take into
> account? (like the one in version 24 - removing the C)
>

This might be a start:
https://wiki.mozilla.org/JavaScript:SpiderMonkey:LongTermPlans

A big one is the upcoming removal of JSContexts. If you can, you should
just use one JSContext per JSRuntime, which will make the transition pretty
painless.

bholley
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Till Schneidereit-2
On Thu, Mar 27, 2014 at 9:13 AM, Bobby Holley <[hidden email]> wrote:

> On Thu, Mar 27, 2014 at 9:56 AM, <[hidden email]>
> wrote:
>
> > Hi there!
> >
>
> Hi!
>
>
> > I would like to know if there are any chances to revert the C API for
> > JSAPI in the new release or in the future.
> >
>
> The chances of this are basically nil. It's near-impossible to properly
> interface with a moving garbage collector without RAII helpers, which C
> doesn't have. :-(
>
>
> > I am implementing a PostgreSQL support for the libjssql extension [1]
> > which currently uses the C API from JSAPI and I would like to know if I
> > should port the current functionality to C++.
> >
>
> You should port to C++.
>
>
> > Also it would be very helpful if you could tell me about your plans with
> > the new release. Will you make important changes which I should take into
> > account? (like the one in version 24 - removing the C)
> >
>
> This might be a start:
> https://wiki.mozilla.org/JavaScript:SpiderMonkey:LongTermPlans
>
> A big one is the upcoming removal of JSContexts. If you can, you should
> just use one JSContext per JSRuntime, which will make the transition pretty
> painless.
>
> bholley
>

Hi Claudiu,

in addition to what bholley says, we're currently evaluating our options
and priorities regarding the future of our embedding API. One of the
options is to create a clean, coherently-designed and stable API that
exposes a commonly-used subset of the engine's embedding functionality.

In order to be able to properly evaluate this option, it'd be extremely
helpful to get an idea of embedders' needs. So if you were able to give a
rough idea of how you'd need to interact with the engine, this would be
very valuable information for us.


thanks,
till
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Anthony Catel-4
Embedders's needs are the same than Firefox developers needs.
If a Firefox developer have to use a private APIs (lowercase js::), it
needs to be ported to the public API.

My two cents.

Le 2014-03-27 17:28, Till Schneidereit a écrit :

> On Thu, Mar 27, 2014 at 9:13 AM, Bobby Holley <[hidden email]>
> wrote:
>
>> On Thu, Mar 27, 2014 at 9:56 AM, <[hidden email]>
>> wrote:
>>
>> > Hi there!
>> >
>>
>> Hi!
>>
>>
>> > I would like to know if there are any chances to revert the C API for
>> > JSAPI in the new release or in the future.
>> >
>>
>> The chances of this are basically nil. It's near-impossible to
>> properly
>> interface with a moving garbage collector without RAII helpers, which
>> C
>> doesn't have. :-(
>>
>>
>> > I am implementing a PostgreSQL support for the libjssql extension [1]
>> > which currently uses the C API from JSAPI and I would like to know if I
>> > should port the current functionality to C++.
>> >
>>
>> You should port to C++.
>>
>>
>> > Also it would be very helpful if you could tell me about your plans with
>> > the new release. Will you make important changes which I should take into
>> > account? (like the one in version 24 - removing the C)
>> >
>>
>> This might be a start:
>> https://wiki.mozilla.org/JavaScript:SpiderMonkey:LongTermPlans
>>
>> A big one is the upcoming removal of JSContexts. If you can, you
>> should
>> just use one JSContext per JSRuntime, which will make the transition
>> pretty
>> painless.
>>
>> bholley
>>
>
> Hi Claudiu,
>
> in addition to what bholley says, we're currently evaluating our
> options
> and priorities regarding the future of our embedding API. One of the
> options is to create a clean, coherently-designed and stable API that
> exposes a commonly-used subset of the engine's embedding functionality.
>
> In order to be able to properly evaluate this option, it'd be extremely
> helpful to get an idea of embedders' needs. So if you were able to give
> a
> rough idea of how you'd need to interact with the engine, this would be
> very valuable information for us.
>
>
> thanks,
> till
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Till Schneidereit-2
On Thu, Mar 27, 2014 at 12:45 PM, Anthony Catel <[hidden email]> wrote:

> Embedders's needs are the same than Firefox developers needs.
> If a Firefox developer have to use a private APIs (lowercase js::), it
> needs to be ported to the public API.
>

Can you say why that is necessarily the case? Not nearly all embeddings
have requirements that're as complex as Gecko's.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Anthony Catel-4
Le 2014-03-27 17:48, Till Schneidereit a écrit :

> On Thu, Mar 27, 2014 at 12:45 PM, Anthony Catel <[hidden email]>
> wrote:
>
>> Embedders's needs are the same than Firefox developers needs.
>> If a Firefox developer have to use a private APIs (lowercase js::), it
>> needs to be ported to the public API.
>>
>
> Can you say why that is necessarily the case? Not nearly all embeddings
> have requirements that're as complex as Gecko's.

Not nearly all, but some.
I, for one, working on a very large project where JSAPI is central part.
I often see myself having to dig in the js:: space.
Even shell/js.cpp is using private APIs (it was the case not so long
ago).

Complicated things must be sorted out. (e.g. the incremental barrier
thing).
Simple things should me added / virtualised (e.g. UTF8 <=> UTF16 <=>
JSString). (I had to use js::InflateUTF8StringToBufferReplaceInvalid()
recently.)

And... without the stack conservative thing, Exact Stack Rooting API is
*really* a PITA :-( But I guess, there was no other solution in order to
complete with the "performance sphere" :)

> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Till Schneidereit-2
On Thu, Mar 27, 2014 at 1:02 PM, Anthony Catel <[hidden email]> wrote:

> Le 2014-03-27 17:48, Till Schneidereit a écrit :
>
>  On Thu, Mar 27, 2014 at 12:45 PM, Anthony Catel <[hidden email]>
>> wrote:
>>
>>  Embedders's needs are the same than Firefox developers needs.
>>> If a Firefox developer have to use a private APIs (lowercase js::), it
>>> needs to be ported to the public API.
>>>
>>>
>> Can you say why that is necessarily the case? Not nearly all embeddings
>> have requirements that're as complex as Gecko's.
>>
>
> Not nearly all, but some.
> I, for one, working on a very large project where JSAPI is central part.
> I often see myself having to dig in the js:: space.
>

We're aware of the fact that requirements like this exist. What I'm talking
about is extracting a core API that covers the 80% use cases. It sounds
like your needs won't ever be covered by an API that we can keep truly
stable for a long time. And that's fine - it's the same for Gecko and we're
not about to make this situation any *worse* than it is right now. If
anything, the amount of large breaking changes should be much smaller in
the foreseeable future than it was over the last year or two. Exact rooting
obviously was a huge breaking change.


> Even shell/js.cpp is using private APIs (it was the case not so long ago).
>

The shell really is a development tool for the SpiderMonkey team, so it's
to be expected that it isn't cleanly separated from the engine internals.
However, supporting it through a stable API *would* be a nice proof of
concept.


>
> Complicated things must be sorted out. (e.g. the incremental barrier
> thing).
> Simple things should me added / virtualised (e.g. UTF8 <=> UTF16 <=>
> JSString). (I had to use js::InflateUTF8StringToBufferReplaceInvalid()
> recently.)
>

Having a list of exactly this kind of stuff would be really useful.


>
> And... without the stack conservative thing, Exact Stack Rooting API is
> *really* a PITA :-( But I guess, there was no other solution in order to
> complete with the "performance sphere" :)


This is a bit off-topic, really. Still, while performance is one major
motivator, of course, exact rooting isn't only about that. Security
concerns are an additional issue, as are predicability of execution and
other changes to the engine enabled through it.
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

olteanu.vasilica.claudiu
In reply to this post by olteanu.vasilica.claudiu
On Thursday, March 27, 2014 2:56:28 PM UTC+2, [hidden email] wrote:

> Hi there!
>
>
>
> I would like to know if there are any chances to revert the C API for JSAPI in the new release or in the future.
>
> I am implementing a PostgreSQL support for the libjssql extension [1] which currently uses the C API from JSAPI and I would like to know if I should port the current functionality to C++.
>
>
>
> Also it would be very helpful if you could tell me about your plans with the new release. Will you make important changes which I should take into account? (like the one in version 24 - removing the C)
>
>
>
> Happy hacking!
>
> Claudiu

Well, the scope of the project is to be an extension for SpiderMonkey which will provide a generic SQL API for
JavaScript, similar with the JDBC. Currently only a MySql driver is implemented, and I am working on a PostgresSQl
one for my graduation paper.

The current functionality uses JSAPI in order to expose a JavaScript SQL interface.
For the time beeing I can't give you more details because I started working on it a few days ago.
I believe that the user can register the driver (using a driver manager) in his JSContext and he will have access
to a JavaScript API which could be used to connect to a database and query it. So it uses the JSAPI
for the JavaScript data types and to expose new JavaScript methods using a connector to the database.
Also he can use the libjssql extension along with the SpiderMonkey engine in his embedded application in order to expose
the SQL API for JavaScript.

The problem is that the MySQL driver is implemented in C and I wanted to know if I should first port the whole
project to C++ and only after to start implementing the PostgreSQL driver.

All the best,
Claudiu
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Robin Ehrlich
In reply to this post by olteanu.vasilica.claudiu
Our company has been using the excellent SpiderMonkey release for many
years. We have extended the product with many custom objects over the years
using the standard interfaces provided. We have come to dread each release
of SpiderMonkey because so much development is necessary to convert our
objects to the new API interfaces. All of our code is written in C since the
original SiderMonkey was in C. Converting thousands of lines of C into C++
for the new SpiderMonkey APIs is more than we can afford.

We would love to see a standard C interface available. Without such an
interface we will be forced to remain at the 17 release. Please consider the
needs of you many devoted imbedded implementers.

Robin Ehrlich
NBS Technologies

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Tim-2

On 02/04/14 08:10, Robin Ehrlich wrote:
> Our company has been using the excellent SpiderMonkey release for many years. We have extended the product with many custom objects over the
> years using the standard interfaces provided. We have come to dread each release of SpiderMonkey because so much development is necessary to
> convert our objects to the new API interfaces. All of our code is written in C since the original SiderMonkey was in C. Converting thousands
> of lines of C into C++ for the new SpiderMonkey APIs is more than we can afford.
You don't need to do a full-blown c++ port, just make the C-code compatible with a c++ compiler. This is what we did with gjs and its not nearly
as painful as you might imagine.
>
> We would love to see a standard C interface available. Without such an interface we will be forced to remain at the 17 release. Please
> consider the needs of you many devoted imbedded implementers.
As already mentioned in this thread, Spidermonkey now uses c++ features, that are simply not possible in C!
>
> Robin Ehrlich
> NBS Technologies
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Till Schneidereit-2
On Wed, Apr 2, 2014 at 12:38 AM, Tim <[hidden email]> wrote:

>
> On 02/04/14 08:10, Robin Ehrlich wrote:
> > Our company has been using the excellent SpiderMonkey release for many
> years. We have extended the product with many custom objects over the
> > years using the standard interfaces provided. We have come to dread each
> release of SpiderMonkey because so much development is necessary to
> > convert our objects to the new API interfaces. All of our code is
> written in C since the original SiderMonkey was in C. Converting thousands
> > of lines of C into C++ for the new SpiderMonkey APIs is more than we can
> afford.
> You don't need to do a full-blown c++ port, just make the C-code
> compatible with a c++ compiler. This is what we did with gjs and its not
> nearly
> as painful as you might imagine.
> >
> > We would love to see a standard C interface available. Without such an
> interface we will be forced to remain at the 17 release. Please
> > consider the needs of you many devoted imbedded implementers.
> As already mentioned in this thread, Spidermonkey now uses c++ features,
> that are simply not possible in C!
>

Mostly, this means RAII helpers, which we heavily depend on for exact stack
rooting. It is possible to have a C API by providing explicit functions for
initializing and tearing down these RAII helpers. However, we don't have
the bandwidth to support such an API, and using it would be pretty arduous.

The end result is that, as Tim says, it's probably much easier to make the
parts of your C code that interface with our API compilable as C++.

Having said all this, we'd be very interested in learning about the parts
of our API you're using: we're thinking about extracting a subset of
functionality to support through a coherently-designed and stable API.
(Note that "thinking about" means exactly that, not that we have any
specific plans in place.) For more details on this than your probably care
to read, see here:
https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/Zp4WNsY4AAo


cheers,
till
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: [Release 31] C API

Tim-2

On 02/04/14 19:47, Till Schneidereit wrote:
> The end result is that, as Tim says, it's probably much easier to make the parts of your C code that interface with our API compilable as C++.

As a total guess, I would estimate that porting gjs from 17 to 24 took approximately (total dev time wise)
20% - making C code C++ compatible
80% - dealing with the usual undocumented jsapi changes...

Overall it was less work than the 10->17 transition

Tim




_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine