<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<STYLE id=mysingle_style type=text/css>P {
        MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
}
TD {
        MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
}
LI {
        MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
}
BODY {
        FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN: 10px; LINE-HEIGHT: 1.4
}
</STYLE>

<META content=IE=5 http-equiv=X-UA-Compatible>
<META content=IE=5 http-equiv=X-UA-Compatible>
<META name=GENERATOR content="MSHTML 11.00.9600.17842"></HEAD>
<BODY>
<P> </P>
<P> </P>
<P>------- <B>Original Message</B> -------</P>
<P><B>Sender</B> : huanhuan zhu<huanhuan.zhu@samsung.com> Senior Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics</P>
<P><B>Date</B> : Jun 03, 2016 11:54 (GMT+08:00)</P>
<P><B>Title</B> : Re: ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))</P>
<P> </P>
<META content=IE=5 http-equiv=X-UA-Compatible>
<META content=IE=5 http-equiv=X-UA-Compatible>
<META name=GENERATOR content=ActiveSquare>
<META content=IE=5 http-equiv=X-UA-Compatible><X-BODY>
<P> </P>
<P> </P>
<P>------- <B>Original Message</B> -------</P>
<P><B>Sender</B> : huanhuan zhu<huanhuan.zhu@samsung.com> Senior Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics</P>
<P><B>Date</B> : Jun 03, 2016 11:41 (GMT+08:00)</P>
<P><B>Title</B> : Re: Dev Digest, Vol 33, Issue 19</P>
<P> </P>
<META content=IE=5 http-equiv=X-UA-Compatible>
<META content=IE=5 http-equiv=X-UA-Compatible>
<META name=GENERATOR content=ActiveSquare>
<META content=IE=5 http-equiv=X-UA-Compatible><X-BODY>
<P>Hi All</P>
<P>This is Zhu huanhuan who worked NDK project in TV before.</P>
<P>Let me give my personal opinion,</P>
<P><STRONG>A. Why we need NDK ?</STRONG></P>
<P>It is not used for application development directly, it is used for game engine porting their module over Tizen.</P>
<P>So we do not need to care about UI/FW or language, 3rd developers do not care.</P>
<P> </P>
<P><STRONG>B. Why NDK need SDL ?</STRONG></P>
<P>1. Not exactly, we can also refer Android to supply Surface and EGL init & OpenGLES call directly ( I think it is also good)</P>
<P> </P>
<P><STRONG>C. Analysis SDL.</STRONG></P>
<P>1. SDL similar as windows application, application side hold main-loop itself.</P>
<P>SDL does not care how to integrate platform's appframework who is incharge of lifecycle management.</P>
<P>For example all application in windows need a X button and close itself. TaskManager just do kill one process works.</P>
<P>main() is the entrance of application directly.</P>
<P>2. Android / Tizen which has internal glib's g_main_loop to handle the main-loop.</P>
<P>The AppManager want to handle to launch and terminate works by OS directly and front-ground/back-ground case.</P>
<P>So application need register render callback based main-loop and app manager is handled in OnXXX callback.</P>
<P> </P>
<P>For android case, it use one thread to handle lifecycle and render.</P>
<P>For EFL case, it is same but it has a problem of integrate EGL inside.(which is a issue I will talk latter)</P>
<P>For Dali case, it divides two thread for lifecycle and render , which I think is a waster of performance.</P>
<P> </P>
<P><STRONG>So SDL has issue now in Tizen.</STRONG></P>
<P>1. How to integrate to AppFW if main-loop conflict exist.</P>
<P>Let's see how android do for SDL, it create similar structure as dali, event thread(main thread) for applifecycle and inputs, render thread for SDL to handle SDL main-loop. So two thread is needed ( Somehow a waste) One is for Ecore, another is for SDL main</P>
<P> </P>
<P> </P>
<P>Is there other solution ?</P>
<P>Yes, we can refer Android NDK case directly,  but issue exist that evasGL is conflict pure EGL</P>
<P>that we can not use EFL window, so it will be look like that:</P>
<P>Ecore+ EcoreX/EcoreWayland window create</P>
<P>Get surface and pass to user,</P>
<P>User do EGL init and call OpenGLES api directly</P>
<P>Handle inputs from XInput or Wayland inputs.</P>
<P> </P>
<P>BR</P>
<P>Zhu huanhuan</P>
<P> </P>
<P> </P>
<P> </P>
<P>------- <B>Original Message</B> -------</P>
<P><B>Sender</B> : dev-request@lists.tizen.org<dev-request@lists.tizen.org></P>
<P><B>Date</B> : May 30, 2016 20:00 (GMT+08:00)</P>
<P><B>Title</B> : Dev Digest, Vol 33, Issue 19</P>
<P> </P>Send Dev mailing list submissions to<BR>dev@lists.tizen.org<BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>https://lists.tizen.org/listinfo/dev<BR>or, via email, send a message with subject or body 'help' to<BR>dev-request@lists.tizen.org<BR><BR>You can reach the person managing the list at<BR>dev-owner@lists.tizen.org<BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of Dev digest..."<BR><BR><BR>Today's Topics:<BR><BR>   1. Re:  ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))<BR>   2. Re:  ??SDL?support?on?Tizen (Peter)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Mon, 30 May 2016 16:26:37 +0900<BR>From: Carsten Haitzler (The Rasterman) <TIZEN@RASTERMAN.COM><BR>To: Peter <JINI@ZEUS.NET.AU><BR>Cc: "dev@lists.tizen.org" <DEV@LISTS.TIZEN.ORG><BR>Subject: Re: [Dev] ??SDL?support?on?Tizen<BR>Message-ID: <20160530162637.1b33c172124636a55bf9e53f@rasterman.com><BR>Content-Type: text/plain; charset=UTF-8<BR><BR>On Mon, 30 May 2016 16:41:41 +1000 (AEST) Peter <JINI@ZEUS.NET.AU>said:<BR><BR>> ?<BR>> Thanks Carsten,<BR>> <BR>> Yes java jni code generation. ?Thanks for the references this helps a lot.<BR><BR>:) On the same page then.<BR><BR>> It's a shame Eolian use doesn't extend to Tizen api's, perhaps Samsung may<BR>> reconsider??<BR><BR>I have suggested it many times. Evenm if all it was was a simple eo wrapper<BR>on top of existing native API's, then we'd get "binding auto generation" for<BR>free. The more languages eolian supports, tyhen the more languages come "fore<BR>free". (someone has to run the generator to generate bindings - EFL runs it<BR>just as part of "make", tizen native API's could do whatever they wanted as<BR>long as it is run).<BR><BR>> Samsung: Automation trumps manual editing every time, the parser and<BR><BR>Absolutely. That is the premise behind doing auto-generation. We have done<BR>manual bindings many times for EFL. The Python bindings are still manually<BR>maintained and they are always behind the C API and lacking features. It's<BR>manual effort. It's boring work. It's painful. It's error-prone.<BR>Auto-generation takes longer to get right (we've been working on this for a<BR>while to get it right and to get it to fit multiple targets), but in the long<BR>run it saves much more time. Slow to start, fast to finish. The big plus is<BR>indeed "no maintenance". If the generator has a bug, it gets fixed there once<BR>for all languages and API's, so at worst the maintenance is this.<BR><BR>> generators will end up being thoroughly tested in the long run, significantly<BR>> reducing bugs and saving many wasted development hours that could be spent on<BR>> more important work. ?<BR><BR>Yup. Bingo.<BR><BR>> Having the worlds most popular programming language running on Tizen makes a<BR>> lot of sense too (It's the language of Android). ?Tiobe index:<BR>> <BR>> Java 21%<BR>> C 13.2%<BR>> C++ 6.7%<BR>> JavaScript 2.3%<BR>> Swift 1.6%<BR>> Objective-C 1.6%<BR><BR>I would happen to agree. Though you missed Python, C#, PHP. :) I think PHP is<BR>inappropriate for Tizen EXCEPT perhaps for making remote UI's that serve HTML5.<BR>Swift I just am not sure about and is too new. C, C++ and Java have been<BR>long-standing top-languages for the last 2 decades for just about as long as<BR>I've seen popularity comparison charts. Even if C were not popular, it's the<BR>lowest level "lingua franca" that just about every runtime, vm, language etc.<BR>relies on (be it just to build on or as the basic ABI), so it's a good base.<BR><BR>Then offer API's in higher level languages so you can include as many<BR>programmers as possible. Personally me and Java have had... not so great<BR>interactions, but I'll definitely say that it's one of the long-standing<BR>popular languages out there.<BR><BR>Objective-C seems to be rapidly on the way out thanks to swift and other forces.<BR><BR>C# I'm just neutral on. I hear good things, but otherwise have no opinion other<BR>than it having been traditionally not accepted among open source circles for<BR>various reasons (some of them good).<BR><BR>JS I'm neutral on too - but of my preferred languages for "dynamic quick and<BR>dirty development" It'd be in my top 2. Lua would be right up there just due to<BR>size and speed.<BR><BR>Python is just incredibly popular especially among learners who are still<BR>getting started.<BR><BR>> Java and C are the only languages with market share in double digits, these<BR>> two together have more than one third of total developer market share.?<BR>> <BR>> The increase in Java last year alone (+4%) was almost twice the total for<BR>> JavaScript. ?<BR>> <BR>> Increasing available apps is more likely to occur if you double the number of<BR>> developers who can write programs for your platform.<BR><BR>I would agree, though we need to do much more than that. We need to have a<BR>"WOW" factor for Tizen, and frankly... we have never had it. Something that<BR>makes people (developers, users, someone) go "WOW ... that's amazing. I WANT<BR>THAT". I can go on all day about things that would have the WOW factor...<BR>things i know by studying of market (developers at least) would make them go<BR>WOW and turn up, but this is not the time or thread for that. :)<BR><BR>> It would make it a lot easier for developers to create native ports of<BR>> Android apps, provided the presentation and application layers are cleanly<BR>> separated.<BR><BR>Agreed.<BR><BR>> Most recent UI's can be defined using xml, including Android, JavaFX and<BR>> Apache Pivot, among many others, which does make me wonder if generators can<BR>> be written to transform these into enlightenment ui components for simple<BR>> applications, the parsers already exist and are open? ?Far superior to<BR>> android emulation.<BR><BR>Possibly.<BR><BR>> The jvm and libs can be stripped down using compact profiles and jvms can<BR>> share class files to reduce start up time ?The jvm is 2x faster than Android,<BR>> although I believe startup can be slower for Java.<BR><BR>TBH I think we need to stand back and re-think how we deal with the OS + apps.<BR><BR>As time goes on, more and more apps bundle libraries, runtimes etc. into the<BR>apps. this just duplicates and creates a mess. Apps bloat out horribly in size.<BR><BR>I think we should split things into 3 groups<BR><BR>1. Core OS.<BR>2. Runtimes/middleware<BR>3. Apps<BR><BR>Runtimes would include the Tizen Web App Runtime. They would include Java if<BR>there. Each runtime would be versioned with a new install per version. Apps<BR>simply indicate which runtime and which version they want. Runtimes would be<BR>installed as package dependencies automatically (and uninstalled when zero apps<BR>reference them after removal).<BR><BR>This would allow runtimes to be updated rapidly where the core os can only be<BR>slowly updated. It would allow new communities to turn up and support specific<BR>runtimes themselves. Enough people want Python - sure. add it to the runtime<BR>"store" and support it. This would by design de-duplicate all the installs<BR>inside every app. It'd keep memory footprint low as mmap()ing the same file for<BR>the same code, since it's shared, uses only one piece of memory rather than 2 or<BR>3 or 4 apps shipping copies of the same code buried in their shipped-with-app<BR>runtimes using many peices multiplying the footprint and I/O needed to load<BR>the data into RAM. It'd keep Tizen efficient AND flexible.<BR><BR>The only thing to really argue is how much should be in the runtimes. Can it<BR>include shared libraries? how will these override system ones (launcher can<BR>just set LD_LIBRARY_PATH for an app...). And security. Now apps depend on these<BR>middleware code blobs... how to ensure they are not compromised. Personally I'd<BR>take the view that any runtime or middleware MSUT be shipped as source. No<BR>binaries. It has to be auditable and compiled/packages by trusted servers, not<BR>the submitters. But that's a long discussion.<BR><BR>> JOGL supports both Jvm and Android platforms for 3D cross platform<BR>> compatibility.<BR>> <BR>> Regards,<BR>> <BR>> Peter.<BR>> <BR>> Sent from my Samsung device.<BR>> ?<BR>> ??Include original message<BR>> ---- Original message ----<BR>> From: Carsten Haitzler <TIZEN@RASTERMAN.COM><BR>> Sent: 30/05/2016 10:58:08 am<BR>> To: Peter <JINI@ZEUS.NET.AU><BR>> Cc: dev@lists.tizen.org <DEV@LISTS.TIZEN.ORG><BR>> Subject: Re: [Dev] ??SDL?support?on?Tizen<BR>> <BR>> On?Sun,?29?May?2016?14:08:57?+1000?Peter?<JINI@ZEUS.NET.AU>?said: <BR>> <BR>> >?Thanks?Carsten, <BR>> >? <BR>> >?Where's?the?best?place?to?start?looking?to?learn?about?Eolian???I've? <BR>> >?done?an?initial?web?search?which?turned?up?some?presentations. <BR>> >? <BR>> >?Is?Eolian?specific?to?Enlightenment,?or?are?there?plans?for?Samsung?to? <BR>> >?use?it?for?other?Tizen?api's?as?well? <BR>> <BR>> eolian?is?specific?to?efl?indeed.?we?wrote?it?specifically?for?the?object?model <BR>> we?created?and?for?the?purpose?of?making?bindings?directly?from?source. <BR>> consider?this?like?gobject?but?with?a?very?different?take?on?how?to?do?a <BR>> generic?object?model?in?c.?eo?(the?object?model)?and?elian?were?built?from?the <BR>> get-go?to: <BR>> <BR>> 1.?be?able?to?back?our?existing?code?and?so?it?requires?specific?and?special <BR>> solutions <BR>> 2.?to?be?able?to?act?as?a?"language?neutral"?IDL?system?to?define?APIs?that <BR>> appear?in?C?but?also?then?map?directly?to?other?languages?-?be?they?statically <BR>> typed?or?dynamically?typed,?explicitly?memory?managed?or?GC'd?like?C+<BR>> +,?JS,?Lua so?far. <BR>> 3.?save?us?work?in?C?by?writing?and?maintaining?boilerplate?C?code?for?us. <BR>> <BR>> this?is?old?and?eo?syntax?has?changed?since?but?it?gives?a?bit?of?a?general <BR>> intro: <BR>> <BR>> https://phab.enlightenment.org/phame/post/view/75/yet_another_c_object_model_-_but_better/ <BR>> <BR>> we?don't?have?the?eo_do()?construct?anymore,?but?eo_add()?can?do?the?same?by <BR>> calling?methods?to?setup?up?an?object?at?construction?time,?so?objects?have <BR>> finalizers?to?call?after?these?setup?methods?are?called.?it's?meant?to?be?a?way <BR>> to?optimize?objects?by?deferring?as?much?work?f?object?creation?as?possible <BR>> until?the?finalize?when?we?know?the?initial?state. <BR>> <BR>> if?you?find?all?the?*.eo?files?in?efl?you'll?see?how?it?works?soon?enough: <BR>> <BR>> ??git?clone?https://git.enlightenment.org/core/efl.git <BR>> ??cd?efl <BR>> ??find?.?-name?'*.eo'?-print <BR>> <BR>> those?eo?files.?from?those?eo?files?C?core/boilerplate?is?generated,?and?then <BR>> the?actual?implementation?code?is?filled?in.?from?those?eo?files?also?the?c++ <BR>> *.hh?files?that?are?the?bindings?are?generated?as?well?as?the?lua?files?(we <BR>> targetted?luajit?making?use?of?ffi?to?bind),?and?if?you?--enable?it,?the?js <BR>> bindings?(c++?v8/node.js?code). <BR>> <BR>> for?java?i?assume?you'd?want?to?generate?possibly?java?code?that?uses?jni?to <BR>> call?the?original?c.?someone?has?to?write?the?eolian_java?generator,?but?there <BR>> is?a?libeolian?that?does?all?the?.eo?file?parsing?and?manages?an?in-memory?db <BR>> of?everything?to?make?it?easy. <BR>> <BR>> no?-?the?rest?of?tizen?doesn't?use?this.?to?date?there?has?been?no?interest. <BR>> they?seem?to?prefer?to?do?things?by?hand. <BR>> <BR>> >?The?JOGL?library?uses?Gluegen?to?generate?it's?java?bindings.??JOGL?has? <BR>> >?a?number?of?different?back?ends,?I?haven't?quite?got?my?head?around?how? <BR>> >?to?create?a?back?end?based?on?enlightenment?yet,?it?did?seem?like?a? <BR>> >?difficult?task.??I?looked?at?some?of?the?gl?application?examples?for? <BR>> >?Tizen?developers?in?Samsung's?sample?programs,?but?decided?to?focus?on? <BR>> >?creating?java?bindings?for?the?Tizen?api's?first. <BR>> <BR>> hmm?ok?-?so?it's?generated.?the?evas_gl?stuff?is?plain?c?functions?just?as <BR>> function?pointers?in?a?struct.?the?eo/eolian?stuff?doesn't?cover?it.?doe?to?its <BR>> nature?it'd?have?to?be?manually?bound. <BR>> <BR>> >?I'm?glad?Enlightenment?isn't?written?in?C++. <BR>> <BR>> at?least?there?are?a?few?of?you.?:) <BR>> <BR>> >?Regards, <BR>> >? <BR>> >?Peter. <BR>> >? <BR>> >?On?28/05/2016?11:01?AM,?Carsten?Haitzler?(The?Rasterman)?wrote: <BR>> >?>?On?Sat,?28?May?2016?10:20:53?+1000?(AEST)?Peter<JINI@ZEUS.NET.AU>??said: <BR>> >?> <BR>> >?>>?I?started?writing?java?bindings?for?Tizen?(on?github).??I?was?impressed?by <BR>> >?>>?the?object?orientated?nature?of?Enlightenment?and?how?easy?it?is?to?hand <BR>> >?>>?craft?java?bindings?for,?following?the?inheritance?hierarchy.??Tools?that <BR>> >?>>?generate?bindings?don't?do?so?well. <BR>> >?>?orly??everyone?keeps?going?"efl?is?not?oo!?make?it?oo!?(rewrite?in?c++?is <BR>> >?>?what?they?mean)".?i?keep?saying?oo?is?a?concept?independent?of?language. <BR>> >?>?efl?does?do?things?relatively?oo-ish.?it?could?be?improved?(and?thats?what <BR>> >?>?all?the?eo?infra?is?for?-?now?it?looks?REALLY?oo?with?a?single?function?for <BR>> >?>?del/unref?of?every?single?object?and?direct?strict <BR>> >?>?inheritance/milti-inheritance?and?more). <BR>> >?> <BR>> >?>?fyi?-?eolian?should?actually?make?it?far?easier?to?generate?bindings.?we <BR>> >?>?already?auto?generate?bindings?for?lua,?js?and?c++?directly?from?the <BR>> >?>?original?.eo?files?for?efl?api.?the?.eo?files?are?written?at?a?high?level <BR>> >?>?abstraction?and?eolian?generates/maintains?the?c?boilerplate?and?there?are <BR>> >?>?various?binding?generators?per?one?of?the?above?languages.?writing?a <BR>> >?>?generator?for?java?shouldn't?be?too?hard?considering?all?of?the?other <BR>> >?>?languages?we?are?already?handling.?this?means?the?core?of?efl?remains?c?and <BR>> >?>?there?is?a?core?c?api?with?the?bindings?sitting?directly?1:1?on?top?of?this <BR>> >?>?handling?reference?counting?and?more.?considering?the?constraints?of?things <BR>> >?>?like?js?and?lua?i?think?java?should?be?easy.?once?you?have?a?generator?then <BR>> >?>?maintenance?is?over.?it's?not?just?re-running?it?to?pull?out?more?api's <BR>> >?>?into?java?whenever?the?libraries?update?and?add?classes?and?methods.?we <BR>> >?>?already?run?the?js,?lua?and?c+ <BR>> >?>?+?generators?every?time?efl?builds?as?part?of?the?efl?makefiles. <BR>> >?> <BR>> >?>>?JOGL?and?JOAL?bindings?already?exist,?but?I?can't?get?access?to?a?native <BR>> >?>>?window?on?which?to?draw. <BR>> >?>?as?below?-?you?will?have?to?re-bind?and?make?jogl?etc.?compatible?api?on <BR>> >?>?top?of?elm_glview?etc.?it?wouldn't?be?hard?at?all. <BR>> >?> <BR>> >?>>?What?I'd?like?is?a?standard?way?to?get?a?window?(full?screen)?on?which?to <BR>> >?>>?draw?using?opengles.???Events?can?be?used?to?gracefully?get?out?of?the?way, <BR>> >?>>?suspend?etc.??I?need?some?kind?of?compatibility?layer?between?JoGL?and <BR>> >?>>?enlightenment?to?make?it?work. <BR>> >?>?technically?with?is?possible,?but?it?looks?more?like: <BR>> >?> <BR>> >?>?create?window?(elm_win),?put?elm_glview?in?win,?show?it,?show?win.?done.?now <BR>> >?>?your?window?is?filled?with?a?glview.?there?are?associated?properties?of?the <BR>> >?>?glview. <BR>> >?> <BR>> >?>?it's?actually?FAR?LESS?code?than?using?egl/glx+native?xlib?or?wayland?for <BR>> >?>?example?(as?i've?been?doing?this?stuff?for?a?long?time...?to?do?this?RIGHT <BR>> >?>?takes?a?fair?bit?of?code?like?getting?visual?and?colormap?right?in?x11). <BR>> >?>?far?far?less. <BR>> >?> <BR>> >?>?the?glview?can?allow?you?to?use?gles2/3?or?1.1?api?on?it?(there?is?a <BR>> >?>?complete?gles?set?of?api's?in?the?evas_gl?api?struct).?did?you?look?at?the <BR>> >?>?glview?examples?in?elementary_test??if?you?enable?direct?rendering?fyi?... <BR>> >?>?you?get?zero?overhead?support?-?no?extra?copies.?the?api?funcs?are?almost <BR>> >?>?all?just?direct?pass?down?except?a?few?like?scissor?stuff?etc.?-?there?is <BR>> >?>?even?a?helper?header?that?removed?the?need?for?glapi->func()?and?allows <BR>> >?>?just?the?old?func<BR>> >()?via?macros?assuming?a?local?var?for?the?api?struct?etc. > <BR>> >?>?but?either?way?for?some?java?bindings?this?should?do?the?work. <BR>> >?> <BR>> >?>>?A?headless?jvm?works,?2d?and?widgets?will,?but?3D?I?haven't?figured?out. <BR>> >?>> <BR>> >?>>?Regards, <BR>> >?>> <BR>> >?>>?Peter. <BR>> >?>> <BR>> >?>>?Sent?from?my?Samsung?device. <BR>> >?>>??? <BR>> >?>>????Include?original?message <BR>> >?>> <BR>> >? <BR>> <BR>> <BR>> --? <BR>> Carsten?Haitzler?(The?Rasterman)?<TIZEN@RASTERMAN.COM> <BR>> <BR>> <BR><BR><BR>-- <BR>Carsten Haitzler (The Rasterman) <TIZEN@RASTERMAN.COM><BR><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Mon, 30 May 2016 21:05:46 +1000<BR>From: Peter <JINI@ZEUS.NET.AU><BR>To: "Carsten Haitzler (The Rasterman)" <TIZEN@RASTERMAN.COM><BR>Cc: "dev@lists.tizen.org" <DEV@LISTS.TIZEN.ORG><BR>Subject: Re: [Dev] ??SDL?support?on?Tizen<BR>Message-ID: <574C1E8A.2080503@zeus.net.au><BR>Content-Type: text/plain; charset=UTF-8; format=flowed<BR><BR><BR><BR>On 30/05/2016 5:26 PM, Carsten Haitzler (The Rasterman) wrote:<BR><SNIP><BR>>> Having the worlds most popular programming language running on Tizen makes a<BR>>> lot of sense too (It's the language of Android).  Tiobe index:<BR>>><BR>>> Java 21%<BR>>> C 13.2%<BR>>> C++ 6.7%<BR>>> JavaScript 2.3%<BR>>> Swift 1.6%<BR>>> Objective-C 1.6%<BR>> I would happen to agree. Though you missed Python, C#, PHP. :) I think PHP is<BR>> inappropriate for Tizen EXCEPT perhaps for making remote UI's that serve HTML5.<BR>> Swift I just am not sure about and is too new. C, C++ and Java have been<BR>> long-standing top-languages for the last 2 decades for just about as long as<BR>> I've seen popularity comparison charts. Even if C were not popular, it's the<BR>> lowest level "lingua franca" that just about every runtime, vm, language etc.<BR>> relies on (be it just to build on or as the basic ABI), so it's a good base.<BR>><BR>> Then offer API's in higher level languages so you can include as many<BR>> programmers as possible. Personally me and Java have had... not so great<BR>> interactions, but I'll definitely say that it's one of the long-standing<BR>> popular languages out there.<BR>><BR>> Objective-C seems to be rapidly on the way out thanks to swift and other forces.<BR>><BR>> C# I'm just neutral on. I hear good things, but otherwise have no opinion other<BR>> than it having been traditionally not accepted among open source circles for<BR>> various reasons (some of them good).<BR>><BR>> JS I'm neutral on too - but of my preferred languages for "dynamic quick and<BR>> dirty development" It'd be in my top 2. Lua would be right up there just due to<BR>> size and speed.<BR>><BR>> Python is just incredibly popular especially among learners who are still<BR>> getting started.<BR>><BR><BR>On that subject, I hear good things about F#, but haven't looked into it <BR>much myself.<BR><BR>>> Java and C are the only languages with market share in double digits, these<BR>>> two together have more than one third of total developer market share. <BR>>><BR>>> The increase in Java last year alone (+4%) was almost twice the total for<BR>>> JavaScript.  <BR>>><BR>>> Increasing available apps is more likely to occur if you double the number of<BR>>> developers who can write programs for your platform.<BR>> I would agree, though we need to do much more than that. We need to have a<BR>> "WOW" factor for Tizen, and frankly... we have never had it. Something that<BR>> makes people (developers, users, someone) go "WOW ... that's amazing. I WANT<BR>> THAT". I can go on all day about things that would have the WOW factor...<BR>> things i know by studying of market (developers at least) would make them go<BR>> WOW and turn up, but this is not the time or thread for that. :)<BR>><BR><BR>Samsung's talking a lot about IoT, for some years I've contributed to a <BR>project called Apache River, which was originally Sun Microsystems Jini, <BR>one of the first IoT systems out there, it was ahead of it's time, <BR>however it never really went mainstream, it's had some significant big <BR>name deployments, what limited it?<BR><BR>What was good about Jini:<BR><BR>    * Dynamic discovery<BR>    * Software as Services<BR>    * Service Registrar<BR><BR>What wasn't soo good:<BR><BR>    * Security was implemented later and was compromised by the need to<BR>      maintain backward compatibility.<BR>    * The JVM changed, runtime namespace was wider than compile time<BR>      namespace, due to ClassLoaders.<BR>    * Network cards and OS's were often configured so that multicast<BR>      discovery needed some additional work to set up.<BR>    * IPv4 networking required configuration.<BR><BR>What stopped it:<BR><BR>    * IPv4 NAT<BR>    * Firewalls blocking multicast<BR><BR>What I take from it, is dynamic network discovery enables things to be <BR>discovered and work without requiring configuration.<BR><BR>IPv6:<BR><BR>    * Multicast<BR>    * Auto configuration<BR>    * Global address space.<BR>    * No NAT.<BR><BR>The internet has become a publish subscriber model, a server on the <BR>internet can only contact clients that have first contacted it.  NAT has <BR>resulted in the loss of the openness of the internet, or the abilities <BR>of peer to peer networks to discover each other dynamically, except on <BR>local networks.<BR><BR>Today we rely on DNS and lookup names, to popular social networking or <BR>cloud applications, placing our data in the hands of large corporations.<BR><BR>The other problem is walled gardens and locked down platforms, where we <BR>place trust in a corporation to audit and check compliance, with little <BR>in the way of transparency.<BR><BR>With IPv6 multicast and autoconfiguration, combined with dynamic <BR>discovery opens the gate to placing the power back in the hands of the <BR>owners of hardware, however as you mention below there remain security <BR>issues and compatiblity issues with OS platforms.<BR><BR>Java almost got the sandbox right, but insecure deserialization has been <BR>a fly in the ointment, but then there are also problems with <BR>constraining resources, so DOS is quite easy for untrusted code, which <BR>really means don't trust unknown code or input.<BR><BR>Perl taint mode was quite an innovation, ensuring the developer always <BR>parsed and validated input.<BR><BR><BR><SNIP><BR>><BR>>> The jvm and libs can be stripped down using compact profiles and jvms can<BR>>> share class files to reduce start up time  The jvm is 2x faster than Android,<BR>>> although I believe startup can be slower for Java.<BR>> TBH I think we need to stand back and re-think how we deal with the OS + apps.<BR>><BR>> As time goes on, more and more apps bundle libraries, runtimes etc. into the<BR>> apps. this just duplicates and creates a mess. Apps bloat out horribly in size.<BR>><BR>> I think we should split things into 3 groups<BR>><BR>> 1. Core OS.<BR>> 2. Runtimes/middleware<BR>> 3. Apps<BR>><BR>> Runtimes would include the Tizen Web App Runtime. They would include Java if<BR>> there. Each runtime would be versioned with a new install per version. Apps<BR>> simply indicate which runtime and which version they want. Runtimes would be<BR>> installed as package dependencies automatically (and uninstalled when zero apps<BR>> reference them after removal).<BR>><BR>> This would allow runtimes to be updated rapidly where the core os can only be<BR>> slowly updated. It would allow new communities to turn up and support specific<BR>> runtimes themselves. Enough people want Python - sure. add it to the runtime<BR>> "store" and support it. This would by design de-duplicate all the installs<BR>> inside every app. It'd keep memory footprint low as mmap()ing the same file for<BR>> the same code, since it's shared, uses only one piece of memory rather than 2 or<BR>> 3 or 4 apps shipping copies of the same code buried in their shipped-with-app<BR>> runtimes using many peices multiplying the footprint and I/O needed to load<BR>> the data into RAM. It'd keep Tizen efficient AND flexible.<BR>><BR>> The only thing to really argue is how much should be in the runtimes. Can it<BR>> include shared libraries? how will these override system ones (launcher can<BR>> just set LD_LIBRARY_PATH for an app...). And security. Now apps depend on these<BR>> middleware code blobs... how to ensure they are not compromised. Personally I'd<BR>> take the view that any runtime or middleware MSUT be shipped as source. No<BR>> binaries. It has to be auditable and compiled/packages by trusted servers, not<BR>> the submitters. But that's a long discussion.<BR>><BR><BR>You're right this is a complex security / compatibilty problem.<BR><BR>I quite liked how Debian's apt packaging system resolved dependencies,  <BR>I also liked how Solaris Zones allowed you to isolate applications, so <BR>you could make the OS and libraries read only, even if the root account <BR>was compromised an attacker would be disappointed.  I liked Solaris a <BR>lot, at least until Oracle closed it, then I lost interest.  There's an <BR>interesting small project called DilOS, that combined the Illumos kernel <BR>(Solaris) with GNU runtime and libraries and apt packaging.<BR><BR>Let's not forget static analysis and LLVM's intermediate representation.<BR><BR>A packaging system that uses an intermediate representation, static <BR>analysis for validation (similar to Java bytecode verification) and JIT <BR>runtime hotspot compiler and architecture independance.<BR><BR>But these are probably fantasies, IT history has shown many times it's <BR>not the best that wins, it's usually one that can establish critical <BR>market share and maintain it.<BR><BR>So if there was an open platform that used an IR package format, static <BR>analysis for validation, automatic configuration and discovery and <BR>searching of services provided by surrounding devices, with encryption <BR>and autogeneration of identify certificates for users and devices, so <BR>they could do things they cannot do now, on an open platform, without <BR>walled gardens or loss of personal data, except to trusted peers without <BR>a middle man, then people may consider...<BR><BR>Cheers,<BR><BR>Peter.<BR><BR><SNIP><BR><BR><BR>------------------------------<BR><BR>Subject: Digest Footer<BR><BR>_______________________________________________<BR>Dev mailing list<BR>Dev@lists.tizen.org<BR>https://lists.tizen.org/listinfo/dev<BR><BR><BR>------------------------------<BR><BR>End of Dev Digest, Vol 33, Issue 19<BR>***********************************<BR><BR>
<P> </P><!--SP:huanhuan.zhu--><!--huanhuan.zhu:EP-->
<P> </P>
<P> </P><!--SP:huanhuan.zhu--><!--huanhuan.zhu:EP-->
<P> </P>
<P> </P><!--SP:huanhuan.zhu--><!--huanhuan.zhu:EP-->
<P> </P>
<TABLE id=confidentialsignimg>
<TBODY>
<TR>
<TD NAMO_LOCK>
<P><IMG border=0 src="cid:BGFC2LL5XOK0@namo.co.kr"></P></TD></TR></TBODY></TABLE></BODY></HTML><img src='http://ext.samsung.net/mailcheck/SeenTimeChecker?do=9226f2572c3ad117eae22a7764369b007963a179112b9c34a9d261258141ffb394c3b6ddffd7613b866466e88a4130cb62e1ac75b522795a07805447a154a46fcf878f9a26ce15a0' border=0 width=0 height=0 style='display:none'>