[Laszlo-dev] What does this mean?

[Max Carlson]

Hey Rami,

We always enjoy your food for thought.  I'm always trying to figure out 
how to best apply our resources - so I get caught up in trying to take 
action :).  Anything we can do to make OL easier for developers to adopt 
and contribute to is a good thing.

Thanks for the feedback, and enjoy Barcelona for me - ooooh the food! 
Churros y chocolate :)

Regards,
Max Carlson
OpenLaszlo.org

On 2/6/10 5:53 PM, Rami Ojares wrote:
> I'm sorry Max,
> I forgot to mention that I am still on holiday in Barcelona :-)
> My comments were in no way whatsoever meant as some plan of action.
> Rather they were meant as observations, just simple food for thought.
> A pastime if you will.
> Not to be taken too seriously but with a grain of salt.
>
> Peace,
> Rami
>
>> If you notice specific issues with the docs, please use the form at
>> the bottom of the page to let us know so can update them.
>>
>> We try to spell out runtime-specific differences here:
>> http://wiki.openlaszlo.org/Runtime_Differences
>> Feel free to edit the wiki page and/or let us know if you run across
>> anything missing!
>>
>> I agree the documentation should clearly state when an API won't work
>> for a specific runtime. Currently, it's possible to check the
>> view/canvas.capabilities hash at runtime and the debugger warns when a
>> runtime doesn't support a feature - which on DHTML can vary depending
>> on the browser. Since this table is currently built at runtime (and
>> the docs are generated at compile time) it's would be hard to automate
>> putting the details into the docs.
>>
>> It's probably best to manually edit the doc comments - the community
>> can help by using the change request form at the bottom of each doc
>> page, and/or filing bugs in JIRA.
>>
>>> I feel that OL should have a core api, objects that need a target
>>> platform specific implementation.
>>> These would be implemented with performance on the target platform in
>>> mind.
>>> If you then develop components using this api, you would know that they
>>> work on all supported platforms.
>>> This api would be concise and conservative (obvious examples: view,
>>> drawview, Timer (oops that's a camelcase :))
>>
>> I've been thinking it would be nice to have a series of classes/mixins
>> that provide subsets of the view APIs. This could help make components
>> lighter and provide some additional clarity to the documentation.
>>
>> Currently, there are core Laszlo Foundation Classes (LFC) APIs (e.g.
>> view, text, inputtext, etc.) and a sprite system that provides
>> services to the LFC for the underlying runtimes. Unfortunately, the
>> sprite API is not currently part of the OL docs but it's available here:
>> http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/kernel/
>>
>> We've tried to move all runtime-specific bits into the kernel. That's
>> been essential for easing multi-runtime development, e.g. when
>> something is broken on a specific runtime, we know there's likely an
>> issue with the kernel code, not the core LFC. This also minimize the
>> amount of code needed to add a new runtime.
>>
>>> Then you could also have target platform api's if needed.
>>> Say, laszlo components coded with as3
>>> And like it already is, you could write code directly meant for one
>>> target platform.
>>
>> It's always possible to call into the underlying runtime when you need
>> to - but you're going to break cross-runtime compatibility. OL
>> provides ways to conditionalize your LZX or script code for a specific
>> runtime - see the lps/components/extensions area for examples of this
>> including drawview, html, etc...
>>
>> So really, you have access to all the underlying runtime goodness you
>> need, when you need it. I often prototype new features this way, then
>> move them into the underlying LFC and optimize as needed.
>>
>>> This would mean cleaning out all the non-crossplatform features from
>>> core objects.
>>> Eg. pixellock or clickregion from view (actually I only assume they are
>>> flash specific)
>>> These could then be brought back using mixins for those who target
>>> flash.
>>
>> OL aims to support of the entire set of APIs across runtimes, where
>> possible. E.g. pixellock works across runtimes, but clickregion
>> currently only works in Flash because the there isn't good clipping
>> path support in DHTML yet (other than with SVG/VML) so it's tricky to
>> provide clickregion support there. And, there isn't really a standard
>> format that works across Flash and DHTML for vector art - SVG is a
>> possibility there. This hasn't been a huge priority for us though, as
>> it's a ton of work for something that folks don't seem to care about.
>>
>> Video is another interesting example - I've been waiting to see how
>> that shakes out, not that Youtube and others are adding native HTML5
>> players, we really should update videoview for DHTML.
>>
>>> Now the components and OL core api are all mixed up.
>>> This adds to confusion.
>> >
>>> Basically my point is that instead of writing more backends, I would
>>> like to see more clarity in the laszlo software stack.
>>> And it is my firm belief that with this added clarity and documentation
>>> OL would become more open.
>>> And prosper better in the opensource community.
>>> Because the biggest reason for not contributing is lack of understanding
>>> and insecurity that rises from the previous.
>>
>> I agree the documentation could use more clarity - if anything,
>> there's a lot there to take in. It would be great to see things broken
>> up into more logical, digestible chunks. lz.view is pretty large and
>> complex now. Please let us know if you can think of other strategies.
>>
>> I also want to see better LZX components. I think that's where the
>> community can help the most, as it's currently the best
>> documented/accessible part of the system.
>>
>> I've been having fun sketching in that domain - making extensive use
>> of mixins. I'm hoping to release something for comment soon.
>>
>> Thanks for your thoughts, let's keep this conversation going!
>>
>>> This does not mean that I am opposed to any backend, of course.
>>>
>>> - rami
>>>
>>>> 6.2.2010 19:34, Raju Bitter kirjoitti:
>>>>> Check out what the haXe folks did
>>>> Damn! I wasn't aware of this haxe at all.
>>>> Looks pretty good on paper.
>>>> Architecture has the kind of clarity I wished OL would have.
>>>> Has anyone done any comparisons between OL and haxe?
>>>>
>>>> - rami
>>>
>