Re: Browser as Platform (was DesignBais - Impressive)




Tony Gravagno wrote:
"dawn" wrote:
... There are many challenges, such as
security issue and the variety of options, none great it seems, for
storing state on the client -- will sessions be managed on the client,
for example. (If someone really likes their approach for saving state
on the client, let me know -- I have not done enough experimenting in
this area yet).

Many of these subthreads should have their own completely separate
thread...

Depending on who you talk to there are around nine ways to manage
state. [insert here phrase that makes Chandru scream]

Wish I knew what that was.

The rule of
thumb is to ensure that you have as little state as possible in the
browser.

That is certainly the old rule of thumb and perhaps it will continue
that way, even with a sort-of services approach with the app "in the"
browser and asynch calls to services from there. Given the security on
the client, I don't see how to get away from server-based sessions,
however, otherwise each service call would have to (re)validate the
user. (I'll grant that I might not be making sense -- I could be
missing something).

The most simplistic answer to this (depending on the
technologies being used) is to just store a SessionID in the client in
a hidden form input field (I never use cookies) and then read the
actual state on the server from the database using the SessionID as a
key - if you have decent bandwidth on the LAN, decent memory on the
servers, and you aren't processing millions of simultaneous
transactions, this isn't painful at all.

agreed

I have more questions about the services used by the browser-based app
(by way of asynch calls to URLs that access data, for example) -- the
middle and back tiers. I'm in an uncomfortable
I-have-no-preferred-server-side-language state right now, since I am
trying to work without a Java app-server, like tomcat, on the server.
I still dislike PHP, but it seems the only one convenient for all web
developers.

Cheers! --dawn

Try Mono C#. ;) Open Source, well supported, free, commercially
backed by Novell, and runs on Linux, Mac, Windows, and other
platforms. The ASP.NET model manages state in client and/or server,
as you wish, and generates client-side code so that you don't have to
worry about browser-specific issues. Mod-Mono plugs into Apache and
there is even a low-footprint XSP web server that can be used instead
of Apache to process transactions.

Dawn, this answers every argument you've ever presented here. Outside
of sheer prejudice from thinking that Mono ASP.NET is somehow related
to Microsoft, how can you possibly rule this out without further
investigation?

You keep thinking I have some prejudice, while I just figure I have
finite time and a limited brain. I have somewhat reasonably and
somewhat arbitrarily taken everything that is headed to .NET
development off the table. This is helpful for my own sanity. No one
is going to understand everything about everything, but others will cut
off their interest areas in other ways. Another thing I take off the
table is the next level deep regarding technical details of security.
I care a lot about security, but only learn the details of what is
relevant for a particular project -- I'm not going to figure out how to
have my own certificate, for example, unless a project calls for that.

While I'm only focussed on .NOT (that which is not .NET development or
a predecessor), I'm pleased to know others who are broader or more
MS-centric so that I get second and third-hand impressions from them.
That way I can adjust in the future if it appears to me to be a good
idea to do so.

As for Mono, I have a few issues with it other than just that it is in
my .NET, off the table, category and part of my "keep your sanity,
don't learn about everything" approach. For example, my ISPs do not
support it and I do not maintain my own servers. I'm guessing most
ISPs don't support it with their standard web hosting services, right?
I also think of it as being good for those who are on the .NET (and
related) side of the house already so they can expand their horizons.
But maybe it will also draw others in. I just "feel" that it would
lead me to then dive into all of the MS development tools and practices
at which point my brain will fry. So, I will only care about it if the
need arises from a specific project.

Am I making any sense yet? --dawn

.



Relevant Pages

  • Re: UnauthorizedAccessException when using MSDTC
    ... dispatcher2 is the user logged on the client pc. ... Event Source: Security ... Object Server: SC Manager ... Primary Domain: BLITZ ...
    (microsoft.public.data.ado)
  • Re: Routing and Remote Access - Authentication Failure
    ... because the real client computer can tunel through it's local NAT router, ... travel the Intrenet, join the VPN and access the server, when this feature ... Their security system decided that the server was trying to steel ...
    (microsoft.public.windows.server.networking)
  • Re: WCF security advice (and clarification) needed
    ... You, the client, resolve the foo.mycompany.com hostname within your ... TCP/IP) with that ticket as the security token. ... There are two parties participating in a security scenario, the server ... HTTP supports other authentication ...
    (microsoft.public.dotnet.framework.webservices)
  • RE: Problems with security requirements in Windows WorkGroups.
    ... "A remote side security requirement was not fulfilled during authentication. ... small chat application between a client and a server ... When I try to use the TCP channel I get the error (with NO inner exception ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: VPN -- the next consumer "turnkey"?
    ... I'm not a security expert. ... "A Hamachi system is comprised of backend servers and end-node ... Server nodes track client's locations and provide ... services without providing Hamachi with a list of client IP's. ...
    (alt.internet.wireless)