[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    Re: [CVS] RPM: rpm/rpmio/ rpmjsio.c
From:       Jeff Johnson <n3npq () mac ! com>
Date:       2009-04-21 12:53:20
Message-ID: 7B77165D-4BB4-4099-B9A0-1E6FA53EEB2B () mac ! com
[Download RAW message or body]


On Apr 21, 2009, at 8:37 AM, Anders F Björklund wrote:

> Jeff Johnson wrote:
>
>> Sorry for the b0rkage. rpmio/rpmjsio.c will be short lived,
>> will end up in js/* when finished.
>
> No problem, just checking out the development (pun intended).
>

More seriously ...

What do you want the I/O methods to look like in RPM embedded
javascript?

The "traditional" approach to I/O in JavaScript appears to
be through the File class which incorporates (I think, dunno)
methods very similar to what is in Java.

I diddled up rpmjsio.c solely to see if I could resurrect
__SOME__ I/O methods without getting RPM hitched up into
Mozilla NSPR and whatever other madness hides down there.

Meanwhile, I find the I/O methods as implemented in the JS File
class just strange and clunky and hard to use.

So I'm muddling whether I should just add fopen(3) et al
methods to javascript straight from rpmio Fopen(3) et al.
That is certainly the easier impedance match to achieve.

But there may be issues with the security model that is also
dragged in from NSPR.

I do know that I most definitely do not want/need NSPR in RPM.
I'm way happier with Fopen(3) and yarnLock() instead atm.

Other suggestions? I'm likely about a week away from having
to commit to __SOME__ I/O methods in RPM embedded JavaScript.

73 de Jeff______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

[prev in list] [next in list] [prev in thread] [next in thread]