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