Ummm... I still prefer the syntax
$patient('conditions', 'description').get();
or something alike.
I would think about having get and set with callback:
$patient('conditions', 'description').get(function (err, value) { ... } );
$patient('conditions', 'description').set(value, function (err, value) {
... } );
Alternatively
$patient('conditions','description').set(value);
$patient('conditions','otherdescription').set(value);
...
$patient.commit(function (err, result) { ... } ));
I see your layers on Cache, GM.T, but I don't sure if you need async
JavaScript to access the Mumps database implementation. But I can imagine
native JavaScript Mumps database reimplementation, with persistence in a
relational database, that would need async get/set
Angel "Java" Lopez
@ajlopez
On Tue, Jan 29, 2013 at 4:59 AM, rtweed <[email protected]> wrote:
> 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]> 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(**na**me)
>>>> for (var name in proxy) {...}: handler.iterate()
>>>> Object.keys(proxy): handler.**ke**ys()
>>>>
>>>> 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.**fourthwatchsoftwar**
>>>>> e.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-**he**lp/<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-**Gui**delines<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/**grou**ps/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<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 and stop receiving emails from it, send
>>> an 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 and stop receiving emails from it, send an
> 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.
