Sounds good to me. Agree on this idea. Maybe universal API could be one another option...
On Mon, Apr 1, 2019 at 6:32 PM Xavi Artigas <xavierarti...@gmail.com> wrote: > Hello everybody, > > TL;DR: Current docs are a mess because of inconsistent naming of the two > APIs (old and new). I propose we call them Classic and Unified and revamp > the docs site. > > As you know, we have all been laboring in the past years to produce a new > API for EFL that presents a unified look (instead of a collection of > libraries), and which is described through a high-level language (Eolian) > so it is straightforward to write bindings for languages other than C > (instead of having to write and maintain manual bindings). > > This new API is now mature enough that parts of it have been declared > stable and will be shipped in this release (1.22) without BETA markers. > This means apps can be written using this API without requesting any > special BETA access, and they have a certain degree of confidence that they > will continue working in future versions of EFL without change. Actually, > only the Window class has been stabilized, so no great apps will come out > of it, but we're getting there. > > Unfortunately, we never agreed to any name for this new API (that I am > aware of), which makes things hard to document: > - The old API is being called Legacy API, but that's confusing because it's > the ONLY API apps can currently use. > - The new API has been called Interfaces API, but that is confusing because > "interface" is a programming term, and they are present in both APIs. > - Beta API is also a bad name, because parts of the old API are still beta, > and parts of the new API are not beta anymore. > - And obviously "old" and "new" are extremely non-future-proof names for an > API. What are we going to call the new one? (say "newer", I dare you). > > THEREFORE, I propose we start calling the old API "*Classic API*" and the > new one "*Unified API*". > The Unified API presents a unified look of the library, and contains all > EFL symbol starting with efl_ or eina_. > Conversely, the Classic API is a collection of libraries which have grown > organically over the years (hence "Classic") and contains the rest of > symbols (evas_, ecore_, edje_, ...) > This naming will only affect documentation (website, tutorials, reference > guide). No changes in code. > It might not seem like a big deal, but the current state of our docs is > pretty confusing, and having things properly named and introduced will help > newcomers a lot. And we do want newcomers, right? > > So please share your thoughts about the Classic and Unified names, make > other proposals if you wish, and I'll start revamping the docs site. > > Xavi > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards, Hermet _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
