Tim,

Thanks for all the posts on the issues raised this weekend. Rather than
respond to them individually, I thought I'd do it collectively.

Firstly, through the struggles over the weekend, and with great help from
Raul and Uli, I found all the bits and pieces I had been seeking earlier. I
am still running the initial build, which seems not to have the DataSet
Manager demonstrated in the great videos you pointed me to. I did try to
download an interim build either Friday or Saturday but it didn't seem to
work right for some reason and I was left with the initial build. However, I
just decided to uninstall EWB and start over. I apparently did successfully
downloaded the correct install exe this weekend (100b1ewb.exe), with a
7/18/12 build, so I reinstalled and it does have the DataSet Manager
displayed, so I'm probably go-to-go for now. I now see on-screen what your
videos showed.

Sometimes frustration works to your advantage. Thanks to the struggles you
sometimes wind up understanding things better. In any event, I am no end of
impressed with what you have done here. I will surely have questions as I
begin to flesh out some apps (given the HTTP datagram nature, the concept of
"user session" comes to mind, but this can be coded).

Once again, thanks for all your efforts.

Jerry

Jerry,

My suggestion is that server side should be stateless and only state you
have is in your EWB app.

Raul


On 7/23/2012 3:24 PM, Jerry Clancy wrote:
> nature, the concept of "user session" comes to mind, but this can be
> coded).

Jerry,

<< Firstly, through the struggles over the weekend, and with great help from
Raul and Uli, I found all the bits and pieces I had been seeking earlier. I
am still running the initial build, which seems not to have the DataSet
Manager demonstrated in the great videos you pointed me to. I did try to
download an interim build either Friday or Saturday but it didn't seem to
work right for some reason and I was left with the initial build. However, I
just decided to uninstall EWB and start over. I apparently did successfully
downloaded the correct install exe this weekend (100b1ewb.exe), with a
7/18/12 build, so I reinstalled and it does have the DataSet Manager
displayed, so I'm probably go-to-go for now. I now see on-screen what your
videos showed. >>

Good. There have been a lot of changes since the DataSet Manager was first
introduced, so using an older build like that is really just fighting an
unnecessary battle.

<< Sometimes frustration works to your advantage. Thanks to the struggles
you sometimes wind up understanding things better. In any event, I am no end
of impressed with what you have done here. I will surely have questions as I
begin to flesh out some apps (given the HTTP datagram nature, the concept of
"user session" comes to mind, but this can be coded). >>

Thanks, and stay with it.  Once you start to do more of this type of
development, it really starts to grow on you because it opens up a lot of
possibilities that aren't possible with just native desktop applications.
Of course, that isn't to say that native desktop applications don't have
their place, just that each has its own unique set of built-in capabilities
that work in its favor.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

What he said. A colleague said that we should do a new system we were building
using the REST system. Seemed rather limited to me, but at the end it was perfect.
No state is held on the server, and that also makes it very scalable. It is all
very protectable too, so you can pass in passwords etc (we only allow https to
enforce SSL) to make sure that every call can be validated.

My advice is to forget about "low level table access" and instead create an
interface using REST. It will serve you better long term (we now have desktop,
phone and EWB apps talking to the same REST interface).

/Matthew Jones/

<<My advice is to forget about "low level table access" and instead create an
interface using REST. It will serve you better long term (we now have desktop,
phone and EWB apps talking to the same REST interface).>>

Matthew
Totally agreed.
This is clearly the way to go.
We have the same architecture.
Mark

Raul,

Our apps need state on the server side for proprietary reasons. It also
avoids the incessant opening and closing of resources and maintains
continuity and avoids the need for constant logging in. I have no problem
with maintaining it.

Jerry

"Raul" <raul@removethis.raul.ca> wrote in message
news:9A637315-90F5-41F1-8FDF-460D9E8C5A9C@news.elevatesoft.com...
> Jerry,
>
> My suggestion is that server side should be stateless and only state you
> have is in your EWB app.
>
> Raul
>
>
> On 7/23/2012 3:24 PM, Jerry Clancy wrote:
>> nature, the concept of "user session" comes to mind, but this can be
>> coded).
>

I which case, have a look at RemObjects SDK. It is able to handle client state for
you, and also lifetime etc. The only issue I have with it at the moment is that I
always encrypt the channels, but the JSON interface currently isn't. It is all new
though, so I expect it will come.

/Matthew Jones/

I think the current RO strategy is to use https rather than channel
encryption - I'm sure I read a comment from Marc Hoffman that that's
what they'll be focussing on.

Cheers, Bob


On 25/07/2012 11:46, (Matthew Jones) wrote:
> I which case, have a look at RemObjects SDK. It is able to handle client state for
> you, and also lifetime etc. The only issue I have with it at the moment is that I
> always encrypt the channels, but the JSON interface currently isn't. It is all new
> though, so I expect it will come.
>
> /Matthew Jones/
>

That should read "content encryption" of course...


On 25/07/2012 14:40, Bob Devine wrote:
> I think the current RO strategy is to use https rather than channel
> encryption - I'm sure I read a comment from Marc Hoffman that that's
> what they'll be focussing on.
>
> Cheers, Bob
>
>
> On 25/07/2012 11:46, (Matthew Jones) wrote:
>> I which case, have a look at RemObjects SDK. It is able to handle
>> client state for
>> you, and also lifetime etc. The only issue I have with it at the
>> moment is that I
>> always encrypt the channels, but the JSON interface currently isn't.
>> It is all new
>> though, so I expect it will come.
>>
>> /Matthew Jones/
>>
>

We get asked the encryption question as well as i just can't see a
scenario where it would be useful/workable:

1. one should always use TLS/SSL to prevent listening in or otherwise
snooping on traffic. If you need to do bit better then issue client
certificates.

2. Use user authentication in the app : username/password or similar.

3. Nature of Javascript is such that any other encryption would be
easily crackable for anybody that has access to the app (and TLS/SSL
prevents those with no access to gain anything ).

Raul

On 7/25/2012 10:21 AM, Bob Devine wrote:
> That should read "content encryption" of course...
>
>
> On 25/07/2012 14:40, Bob Devine wrote:
>> I think the current RO strategy is to use https rather than channel
>> encryption - I'm sure I read a comment from Marc Hoffman that that's
>> what they'll be focussing on.
>>
>> Cheers, Bob
>>
>>
>> On 25/07/2012 11:46, (Matthew Jones) wrote:
>>> moment is that I
>>> always encrypt the channels, but the JSON interface currently isn't.