By "harmony" I mean: node --harmony
Rick
On Monday, January 28, 2013, Rick Waldron wrote:
> If you expect the code to work in one years time, don't use harmony
> proxies.
>
> 1. The implementation in v8 is not the latest Proxy spec...
> 2. The spec itself is still in flux, though close to completion.
> 3. Once the Proxy spec is reified and v8 updates, I doubt there will be
> any grace period, as flag features are "use at own risk".
>
>
> Rick
>
>
>
> On Monday, January 28, 2013, rtweed wrote:
>
>> Marcel
>>
>> I can't say your suggested Harmony proxies look any more natural to me
>> than the APIs I've suggested - maybe I'm missing something.
>>
>> As to the need for something to overcome the synchronous nature of the
>> interface to Mumps, fibres may be an answer, but meanwhile I've onwardly
>> developed my original Q-Oper8 Node.js module and morphed it into my
>> ewdGateway2 module. I've not introduced it or documented it yet, but it
>> provides the basis of a full-blown web app framework for Mumps-based apps,
>> based around my EWD technology. More information will follow soon.
>>
>> Last time I looked, fibres wasn't available for Windows which is why I
>> didn't pursue is as the basis for ewdGateway2 - is this still the case or
>> have things moved on?
>>
>> Rob
>>
>>
>>
>> On Monday, January 28, 2013 11:57:11 PM UTC, Marcel wrote:
>>>
>>> > I've not heard of Harmony proxies but I'll take a look and see what
>>> you're suggesting.
>>>
>>> You really should. They basically give you "catch all" methods on
>>> objects which would let you make an API that more closely resembles the
>>> simplicity of Mumps that you're going for. Here's the operations you get:
>>> proxy[name]: handler.get(**proxy, name)
>>> proxy[name] = val: handler.set(proxy, name, val)
>>> name in proxy: handler.has(name)
>>> delete proxy[name]: handler.delete(**name)
>>> for (var name in proxy) {...}: handler.iterate()
>>> Object.keys(proxy): handler.**keys()
>>>
>>> So instead of that setValue() function or whatever you had, you could
>>> just use regular JS.
>>>
>>> I think Eric's idea for writing a Mumps interpreter isn't a bad idea. I
>>> looked over the wikipedia pages for this language and it doesn't seem very
>>> complex at all. I don't have an intimate understanding of the language but
>>> it seems possible to write a source-to-source transformation into JS as a
>>> weekend project. Seems like this would drastically reduce the complexity of
>>> your infrastructure, and you get all the speed and research that went into
>>> v8. The biggest thing you need to reconcile (and a question you really need
>>> to think about) is the difference between Mumps' synchronous design and
>>> Node's async design. I hate to be "that guy" but Fibers might be an answer
>>> to that (disclosure: I wrote Fibers).
>>>
>>> On Mon, Jan 28, 2013 at 4:16 AM, rtweed <[email protected]> wrote:
>>>
>>>> Marcel
>>>>
>>>> As you note, from the basic technical point of view, the key building
>>>> blocks are now in place. I've not heard of Harmony proxies but I'll take a
>>>> look and see what you're suggesting.
>>>>
>>>> I think I'm trying to make several things happen:
>>>>
>>>> - wake up the current vendors of Mumps-based healthcare applications to
>>>> Node.js as a way for them to attract new blood into their development
>>>> community. In particular the US Dept of Veterans Affairs, the US Dept of
>>>> Defense and the Indian Health Service need to see this as a solution to a
>>>> long-term problem they've never previously had a sensible way of
>>>> addressing. They need to learn about Node.js and start focusing their
>>>> minds on moving away from the Mumps language and towards Javascript (and
>>>> stop messing about with other, lesser and inappropriate technologies which
>>>> is what has tended to happen in the past).
>>>>
>>>> - wake up the Node.js community to the opportunity afforded by this
>>>> huge healthcare IT sector. To this end, a good first step will be striking
>>>> up a dialogue with Luis Ibanez (who has posted in this thread) and using
>>>> the resources of OSEHRA to find out more about how to get into this
>>>> marketplace (Luis is doing a lot of work getting training courses and
>>>> tutorials developed) and how to find out more about Mumps-based
>>>> applications such as VistA. As Luis has said, this marketplace requires
>>>> thousands of new developers instead of the relative handful of developers
>>>> it now employs.
>>>>
>>>> - get others in the Node.js community to build on what I've already
>>>> created. Much of that work, at least initially, will critically require a
>>>> coming-together of the mindsets of the Mumps and Node.js developer
>>>> communities. The extensive real-world experience of the Mumps development
>>>> community (who understand how to best use Global Storage for healthcare
>>>> application use) needs to come together with the new and modern ideas and
>>>> development approaches of the Node.js community in a way that brings the
>>>> best out of both - both sides need to understand and recognise the skills
>>>> and benefits of the other: it's going to be a fine balance, at least to
>>>> begin with. What I've created is merely a start, but it has the benefit of
>>>> having been developed by someone who understands the mindset of the Mumps
>>>> developer AND the Node.js developer and, I believe, correctly bridges those
>>>> two communities.
>>>>
>>>> One example of a necessary next step: in VistA, almost all of the
>>>> database access is done indirectly via an extensive set of APIs known as
>>>> the Fileman APIs. Very little direct access to the underlying Globals is
>>>> done by VistA developers. Those Fileman APIs need abstracting and
>>>> encapsulating in Javascript so they make sense to Node.js developers. This
>>>> is clearly an area where experienced Mumps/Fileman developers need to come
>>>> together with Node.js developers and figure out the correct way to do it -
>>>> it's not an area of expertise for me, but I'd be happy to help get the two
>>>> sides come together to make it happen.
>>>>
>>>> By the way, a good, rapid way in for the Node.js developer is to
>>>> download and fire up the dEWDrop VM (http://www.**
>>>> fourthwatchsoftware.com <http://www.fourthwatchsoftware.com>) which is
>>>> a pre-built, pre-configured, ready-to-run, fully Open Source, GT.M-based
>>>> VM, all set up with the NodeM interface and my OO projection. It also has
>>>> a complete implementation of VistA, pre-configured with in-patient and
>>>> out-patient clinics/wards etc, and complete with a fair amount of test
>>>> patient data. Probably about $3b-worth of software, if you were to base it
>>>> on development costs paid over the years by the VA! I'll post some
>>>> instructions on how to get up and running with my Node.js/OO interface on
>>>> this VM very soon.
>>>>
>>>> Hope this helps
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>> On Monday, January 28, 2013 1:49:55 AM UTC, Marcel wrote:
>>>>
>>>> Rob,
>>>>
>>>> From your articles it's not clear exactly what call to action you're
>>>> trying to make. I scanned over them, particularly part 3, and it seems like
>>>> progress is already pretty far along? You've got access to your DB in
>>>> NodeJS.. Are you looking for assistance in writing a Mumps VM that can run
>>>> Mumps code side-by-side with JS?
>>>>
>>>> Additionally, have you heard of Harmony proxies? Based on what it looks
>>>> like you're trying to do with your GlobalNode API it seems like it would
>>>> make the whole thing much easier to consume. Proxies should be available
>>>> right now in Node by running with the --harmony-proxies flag.
>>>>
>>>> On Sat, Jan 26, 2013 at 5:33 AM, rtweed <[email protected]> wrote:
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "nodejs" group.
>>>> To unsubscribe from this group, send email to nodejs+un...@**
>>>> googlegroups.com.
>>>> For more options, visit
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>
>>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
