[Laszlo-dev] Default value for unproxied operation

[Sarah Allen]

sound like a sane approach

At 03:04 PM 1/18/2005, Oliver Steele wrote:
>How's this for an approach:
>1. For LPS 3.0b2, implement the feature and the final syntax, but not the 
>new default.
>2. Immediately after LPS 3.0b2 is released, flip the switch and make 
>unproxied the default.
>3. See what it takes to fix the existing demos and examples to run 
>unproxied.  Make them run unproxied where possible; add proxied="true" 
>where this isn't possible.
>4. Use what we learn in (3) to decide whether to release LPS 3.0 final 
>with a default of unproxied="false".
>
>We will then have a lot more data about where unproxied operation is 
>problematic by the time we actually make the final decision.  We also 
>won't be on the hook to fix the demos and examples for unproxied 
>operation, within the LPS 3.0b2 timeframe.  (We'll also be missing out on 
>using them as a way to test the feature during the same milestone that 
>it's implemented in, though.)
>
>On Jan 18, 2005, at 5:44 PM, David Temkin wrote:
>
>>My view is that unproxied ("serverless") operation will be the mainstream 
>>mode of Laszlo development/deployment once available, and should 
>>therefore be the default, despite implications for backwards compatibility.
>>
>>The number of developers who can/will write Laszlo apps is, I suspect, 
>>much higher than the subset of those developers who are in a position to 
>>deploy/configure a Java server. I'm hoping "serverless" capability can 
>>make Laszlo development *lots* more widespread than it is today.
>>
>>- David.
>>
>>
>>
>>
>>From: Oliver Steele <steele at laszlosystems.com>
>>Reply-To: OpenLaszlo platform development and bug reporting 
>><laszlo-dev at openlaszlo.org>
>>Date: Tue, 18 Jan 2005 14:25:31 -0500
>>To: OpenLaszlo platform development and bug reporting 
>><laszlo-dev at openlaszlo.org>
>>Subject: [Laszlo-dev] Default value for unproxied operation
>>
>>Should an application default to proxied, or unproxied, operation?
>>
>>(I don't want to discuss in this message the mechanism for specifying 
>>whether an application is proxied or unproxied.  It will probably be 
>>either some UI element in the developer console, or a query parameter in 
>>the URL that is used to request the application executable, or a bit of 
>>syntax in the application's source, or some interaction among all 
>>three.  I just want to decide what mode an application that doesn't 
>>specify anything in its sources, with the default developer console 
>>settings and/or a URL without any query parameters, compiles to.)
>>
>>The advantages of defaulting to unproxied operation are:
>>- Developers will to default to developing applications that work with 
>>LAMP..  Fewer surprises at deployment time.
>>- Developers will to default to developing libraries that work with LAMP.
>>- This is the mode of operation that works in the Preview tab in 
>>IDE4Laszlo (which runs without an LPS instance) --- data and media 
>>requests will work in IDE4Laszlo by default.
>>The disadvantages of defaulting to unproxied operation are:
>>- Several significant features --- RPC, runtime requests for many media 
>>types --- aren't supported.  (But at least these can be detected at 
>>compilation time, and the solution message can tell the developer to turn 
>>off unproxied mode.)
>>- This is a backwards-incompatible change.  If your application uses the 
>>proxied-only features, you will need to either make a change to the 
>>source, or to the default developer console settings, depending upon the 
>>design for creating an unproxied application.  (However, it's not the 
>>worst backwards-incompatible change, and, again, the solution message is 
>>simple.)
>>
>>I was leaning towards defaulting to proxied operation, the same as LPS 
>>2.x, until I wrote down the list of pros and cons.  Now I'm leaning 
>>towards defaulting to unproxied operation.  Obviously this needs more 
>>thinking, and by more people than me...
>>
>>Best,
>>Oliver
>>
>>--
>>Oliver Steele
>>Chief Software Architect
>>Laszlo Systems, Inc.
>>
>>_______________________________________________
>>Laszlo-dev mailing list
>>Laszlo-dev at openlaszlo.org
>><http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>http://www.openlaszlo.org/mailman/listinfo/laszlo-dev 
>>
>>   _______________________________________________
>>Laszlo-dev mailing list
>>Laszlo-dev at openlaszlo.org
>><http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>http://www.openlaszlo.org/mailman/listinfo/laszlo-dev 
>>
><br>
><div>_______________________________________________</div>
><div>Laszlo-dev mailing list</div>
><div>Laszlo-dev at openlaszlo.org</div>
><div><a href="http://www.openlaszlo.org/mailman/listinfo/laszlo-dev" 
>EUDORA=AUTOURL>http://www.openlaszlo.org/mailman/listinfo/laszlo-dev</a></div>
></blockquote></x-html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050118/99e0765c/attachment-0001.htm