On Mon, 1 Apr 2019 15:31:46 +0200 Xavi Artigas <xavierarti...@gmail.com> said:
> Thank you all for your feedback! > > My comments: > Universal works too, but I think Unified is more specific as to its purpose. > I wasn't sure about the Classic name so I welcome alternatives. I like > Components because it clearly states its problem. However, we would need to > explain that "the API that you have been using so far is now called > Components API", whereas you don't need to do that if you call it > "Classic". How about "Components (Classic) API", or "Classic (Components) > API"? > Synonyms for Components: Split, Detached, Separated. > Aaaaaaaand I don't like Best and Worst because we can do better than the > new API and I fear we can do worse than the legacy API :) We gave been calling them LEGACY and EO API. Legacy isn't going away any time soon at all. It'll require a lot of things be ported over first, and in fact Eo API will need to get a lot of expansion and improvements to even make that possible, so it's going to take a long time. Given that this will be around for a long time, probably something like CLASSIC vs. EO will do. EO API is pretty exact on the dot as to what it's based on. CLASSIC is what has classically been around for a long time... and likely will be for a while. > Xavi > > On Mon, 1 Apr 2019 at 14:15, Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > I'd prefer "component" and "unified". They say the classics never go out of > > style, but they do. > > > > On Mon, Apr 1, 2019 at 5:32 AM 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 > > > > > > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
