jsdo open source? - Forum - Mobile - Progress Community

jsdo open source?

 Forum

jsdo open source?

This question is answered

There were plans to make the jsdo opene source. Any idea whan that could become real? Could motivate prospects to step in.

Verified Answer
  • Just saw a post from Edsel today... community.progress.com/.../18212.aspx

    I agree the headline should have been JSDO open sourced but it's there in the post - github.com/.../lib

  • The Cloud Data Object and JSDO are now available on GitHub.

    You can access it using clouddataobject.github.io/CDO

    - Check out all of the links to see the repos in GitHub

    - Any missing items will be deployed by EOD Saturday

    The AppBuilder mobile template is available in both the Telerik Platform and on GitHub so users can easily create Mobile Apps that work with an OE server.

  • The CDO is a specification that defines an API and protocol to handle data synchronization for a remote service. We feel that this could be useful in other languages like Objective-C. The OSS community can contribute to this specification. 

    The JSDO implements this specification in JavaScript. It can be used with any backend REST service. Of course the catalog would need to be created "by hand" if PDSOE is not used. 

    HTH
    Shelley

    On May 27, 2015, at 2:11 AM, "agent_008_nl" <bounce-agent_008_nl@community.progress.com> wrote:

    Reply by agent_008_nl

    Thanks for your reactions. The CDO is new to me. If I understand the links correctly CDO is no more than a rebranding of JSDO? In that case I find JSDO a less cloudy /clearer name I must say, but there will be marketing reasons. Further more the JSDO is positioned as "an implementation of the CDO for a JavaScript"  (why "implementation"?)   "available for a browser or hybrid mobile client running against a Progress OpenEdge® server"  (clouddataobject.github.io/CDO). This is confusing for me also. Bill Wood assured I am not bound to the progress appserver when I use the jsdo community.progress.com/.../55518.aspx. I trusted that this is so, at least when I do not use the built in ablFilter community.progress.com/.../57662.aspx.

    Regards, Stefan.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

All Replies
  • Just saw a post from Edsel today... community.progress.com/.../18212.aspx

    I agree the headline should have been JSDO open sourced but it's there in the post - github.com/.../lib

  • The Cloud Data Object and JSDO are now available on GitHub.

    You can access it using clouddataobject.github.io/CDO

    - Check out all of the links to see the repos in GitHub

    - Any missing items will be deployed by EOD Saturday

    The AppBuilder mobile template is available in both the Telerik Platform and on GitHub so users can easily create Mobile Apps that work with an OE server.

  • Thanks for your reactions. The CDO is new to me. If I understand the links correctly CDO is no more than a rebranding of JSDO? In that case I find JSDO a less cloudy /clearer name I must say, but there will be marketing reasons. Further more the JSDO is positioned as "an implementation of the CDO for a JavaScript"  (why "implementation"?)   "available for a browser or hybrid mobile client running against a Progress OpenEdge® server"  (clouddataobject.github.io/CDO). This is confusing for me also. Bill Wood assured I am not bound to the progress appserver when I use the jsdo community.progress.com/.../55518.aspx. I trusted that this is so, at least when I do not use the built in ablFilter community.progress.com/.../57662.aspx.

    Regards, Stefan.

  • The CDO is a specification that defines an API and protocol to handle data synchronization for a remote service. We feel that this could be useful in other languages like Objective-C. The OSS community can contribute to this specification. 

    The JSDO implements this specification in JavaScript. It can be used with any backend REST service. Of course the catalog would need to be created "by hand" if PDSOE is not used. 

    HTH
    Shelley

    On May 27, 2015, at 2:11 AM, "agent_008_nl" <bounce-agent_008_nl@community.progress.com> wrote:

    Reply by agent_008_nl

    Thanks for your reactions. The CDO is new to me. If I understand the links correctly CDO is no more than a rebranding of JSDO? In that case I find JSDO a less cloudy /clearer name I must say, but there will be marketing reasons. Further more the JSDO is positioned as "an implementation of the CDO for a JavaScript"  (why "implementation"?)   "available for a browser or hybrid mobile client running against a Progress OpenEdge® server"  (clouddataobject.github.io/CDO). This is confusing for me also. Bill Wood assured I am not bound to the progress appserver when I use the jsdo community.progress.com/.../55518.aspx. I trusted that this is so, at least when I do not use the built in ablFilter community.progress.com/.../57662.aspx.

    Regards, Stefan.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

  • Shelley, this means that eventually switching to odata as standard is now definitively ruled out? There are a bunch of vendors that can use odata (including kendo) and PSC (through Data Direct) is part of the committee defining the standard... what is the reason for yet another REST 'standard'?

  • Hi Marian,

    OData is a transport protocol that the JSDO "could" use. We chose a simpler protocol to start. 
    Remember the JSDO is much more than just a wire protocol. 
    As we define new functionality, we are making it OData compliant as that is our future direction. With the JSDO Open sourced, someone in the community could do this. 

    Shelley

    Sent from my iPad

    On May 27, 2015, at 8:37 AM, "Marian Edu" <bounce-medu@community.progress.com> wrote:

    Reply by Marian Edu

    Shelley, this means that eventually switching to odata as standard is now definitively ruled out? There are a bunch of vendors that can use odata (including kendo) and PSC (through Data Direct) is part of the committee defining the standard... what is the reason for yet another REST 'standard'?

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.