Hello Björnke, We probably need to get in mind that desktop apps stacks and server's stacks are not dedicated to do the same jobs !
On the left, desktop apps stacks are handled in RAM as long running processes and this give us lots of possibilities, sockets management included. If you really search a way to handle such stacks in a server-side long running application's server context, feel free to refer and use the method and tools i forwarded to the community years ago about the subject in visiting <http://www.sahores-conseil.com/insead/>. This is a good way to go as long as we remind that the stack component is not running in multithread mode... On the right, LC-server stacks are only dedicated to work as command-line or CGI driven protected libs components and because this restriction they are able to run in multithread mode and this was wanted/needed to get LC-server able to become a rock-solid server-side alternative to Java or PHP. In a perfect world - and this will perhaps become the case later if RunRev get good incomes from the LC-server product - the next step could be to get a new kind of product as an LC-application's server running in the way JBoss, WebSphere, WebLogic, etc... are able to do. But, at this point, frankly, i'm not sure that this way to go would really helps as long as all good n-tier apps relies mainly on methodology, design and good practices to handle their tasks as stateless jobs. In other words, if an n-tier app can be build on top of JBoss (long running process), it can be build as well as a CGI tasks collection too and the difference will mainly rely on the fact that the second code implementation will need to be more clean and compact than the one we could build for JBoss in using toons of unproductive frameworks (Eclipe, Ant, Hibernate, Struts, etc...). Just a simple tough ;-) Kind Regards, Pierre > The stack is a complex beast, and for a reason. It allows for dozens of > different user cases, and to support all of those possibilities, all the > stack features need to be available. There is never one use for any component > in LC, instead everything hooks together to allow the dozens approaches we > all love for achieving a single goal. > > Björnke > > -- > Watch live presentations every Saturday: > http://livecode.tv > > Use an alternative Dictionary viewer: > http://bjoernke.com/bvgdocu/ > > Chat with other RunRev developers: > http://bjoernke.com/chatrev/ > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
