Thanks again Eduard

Just one point it's Angular2 not AngularJS - I think AngularJS could be delivered by CSP but I doubt that it would be the best way to deliver Angular2 
Or so I believe - it's one of the things on my list to look at with Angular 2

Peter

Hi Eduard

Food for thought !!!!

It's just that it's always been the way I have done it in ZEN for around 11 years - started off with "small" result sets and just carried on doing it that way
It's great to be challenged - Thank you!!!

= =

BTW I like the look of the way that you include source code in your posts
Do you care to share how you create the posts with the grey box around them - do you create/edit with the online editor or some other tool?

Peter

Oh forgot this one......

Maintaining State between client calls...

I can think of a real world case where some sort of state between the client and the server is a good idea...

Consider a huge database where we need to query and produce the equivalent of the ZEN tablepane that displays rows of data with filtering and sorting functionality
I can see there are a number of widgets available for different frameworks where the whole result set is shipped to the client and filtering/sorting is done there.

However there are cases were....

  • We want the query to be run once on the server
  • We do not want  to ship the whole resultset  (too big there could be 100,000's rows) to the client and do pagination/sorting/filtering there
  • So the client component needs to get the data page by page from the server - and any filtering/sorting is done there
  • This is just how the ZEN tablepane works using ^CacheTemp(xxx to stash the data
  • Hence we are maintaining a state between the client and server

Unless you can suggest a better alternative that does not require state to be maintained

At the moment this is the only use case that I can think of where maintaining state is a useful thing 

Peter

Hi Eduard

I had already seen your second comment elsewhere - but thanks for the additional detailed comment - most useful.

Just some quick thoughts......

  • All brokers effectively have Parameter UseSession = 1;
    But the default value in %CSP.REST is Parameter UseSession As BOOLEAN = 0;
    So the developer has to remember to override this every time (or sub-class)
     
  • Use same GroupById  
    I have seen this but have no understanding of what it's for - searching the docs only brings up a reference in the automatic deployment section only with no description
    If you have any more information on it's purpose please share 
     
  • Sharing the session between the CSP/ZEN app and Rest calls is a great feature
    But if it's a third party app then there is no CSP/ZEN app - the use case I have in mind is a 3rd party web developer is creating a complex shop system that needs to communicate with Caché
    I have no idea or interest in what technology they are using and it may be that their programming language does not easily support cookies so the CSPCHD (the session cookie) does not get passed.
    I am thinking that in this case the authentication needs to be passed with each Rest call - not an issue
    (or use OAUTH which I know little about)
     
  • On security
    Yes SQL security for sure - but there are traps here in the management of that security - I don't want a huge overhead in having to manage multiple roles each with it's own SQL security profile.
    And anyway it does not help if the Rest application is accessing the database via the object projection rather than SQL

As always, there are many options/scenarios my aim is not to give a definitive answer but to share my experience as a real world developer and how I implement things

Peter

Hi Darren

I remember an Intersystems Global Summit (or DEVCon and it was called back then) around 10 years ago where ISC did a presentation (Robert Nagle) on a  project where they got MIT to develop the same business app using open source and Caché.

It was big data where they were monitoring and capturing real-time data from solar energy installations (from small to large)

The project never fully completed but the indications were that the closed Caché outperformed open source on all metrics.

Interesting to see what's changed!
Just wish I had a copy of the presentation

Peter 

Hi Jeff 

and welcome aboard

If you want more (private) feedback please email me direct

Peter

Hi Evgeny

Source control library is not mine - It was a commercial product created by GlobalWare - saddly did not make it commercially and the company went defunct a few years ago.

But...
The main owner of the company now works for ISC in Boston wrc - Jorma Sunamo by name - maybe you should contact him direct (jorma.sunamo@intersystems.com) to discuss.

Peter

Hey Eduard

This I understand and I use this at the moment in my ZEN apps
But...
Anne needs a JSON restful method of getting a logon and get a session token - only consuming a single license slot.
*NOT* a HTML web page to logon  that a CSP logon delivers - this is not what she is looking for.

As she said, you could pass CacheUsername and CachePassword as a URL parameter - but this don't work - if it fails Cahché delivers a HTML page - not what is required for a restful logon. 

The display/content should be in control of the client UI - not delivering a CSP HTML page

I'm sorry if I seem to be dismissive of your answer - but the web is moving on and we can no longer rely on the "old" way of doing things.

Peter 

Hi Anne

Looks like we are on the same journey - have a look here on what I have so far

= =

I have no real answer to the logon issue - I think the "correct" solution is for Intersystems to provide a restful logon service to provide this functionality that can be accessed without being already logged on.

One possibility that I can think of that *may* work (have not tried it *yet*) ....
create a separate CSP web site that has no restrictions on logging on - with a single restful service "logon"  - in can be in the same namespace but with a different dispatch class.


The COS then performs a $System.Security.Login("username", "password") 
and returns success or fail - and sets up the session token

I can see that there may be issues with CORS - but I don't understand this topic yet :}

= =

As an aside....
I have been working with Caché for (too) may years and their security model/features is hidden away, difficult and subject to change.
I can understand this - they need to protect their commercial interests - eg it is technically possible for a minimal license (5 users) to support 1,000's of end user clients - clearly not commercially sensible.

Peter