Marcel
On Tuesday, January 29, 2013 4:05:44 AM UTC, Marcel wrote:
>
> > 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.
>
> Well, this:
> var desc = patient.$('conditions').$(0).$('description')._value;
>
> Could just be this:
> var desc = patient.conditions[0].description;
>
> And the whole `_fixProperties()` madness would go away entirely.
>
>
Aha! OK - in that case I totally agree with you - if such syntax can result
from using them then then it would be much simpler and much more intuitive.
Can't see yet, though, what the coding will be like to achieve this - The
descriptions I've read of using Harmony Proxies are pretty opaque and I've
not managed to "get it" yet, but I'll persevere. If you have any pointers
that would be relevant to this implementing this kind of use case, I'd
appreciate it.
>
> > If you expect the code to work in one years time, don't use harmony
> proxies.
>
> Idk it seems like Proxies are certainly something that TC39 is pretty
> confident will make it in some form. The surface area in the face of a
> changing API should be pretty low, but yeah obviously he should use them at
> his own risk.
>
> I'll give it a go - I suspect whatever techniques I need to use, any
future change shouldn't be too difficult to adjust downstream as the
standards solidify.
> > 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?
>
> It works on Windows.
>
Excellent - in that case I suspect fibres should provide a faster
architecture than the pre-forked child process + queue that I currently use.
Thanks for the pointers and help!
Rob
>
> On Mon, Jan 28, 2013 at 6:17 PM, rtweed <[email protected]
> <javascript:>>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:
>>>>>
>>>>>> Please see:
>>>>>>
>>>>>> http://robtweed.wordpress.com/****2013/01/26/to-the-node-js-**comm**
>>>>>> unity-healthcare-needs-**your-**help/<http://robtweed.wordpress.com/2013/01/26/to-the-node-js-community-healthcare-needs-your-help/>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Job Board: http://jobs.nodejs.org/
>>>>>> Posting guidelines: https://github.com/joyent/**node**
>>>>>> /wiki/Mailing-List-**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
>>>>>> nodejs+un...@**googlegroups.com
>>>>>>
>>>>>> For more options, visit this group at
>>>>>> http://groups.google.com/**group**/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>> --
>>>> Job Board: http://jobs.nodejs.org/
>>>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-
>>>> **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
>>>> nodejs+un...@**googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/**group/nodejs?hl=en?hl=en<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 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]<javascript:>
>> To unsubscribe from this group, send email to
>> [email protected] <javascript:>
>> 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] <javascript:>.
>>
>> 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.
