[Laszlo-dev] What does this mean?

[Rami Ojares]

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
>>