Component (Classic) seems acceptable, though I think there is still room for people to not understand what is meant by this term.
On Mon, Apr 1, 2019 at 9:32 AM Xavi Artigas <xavierarti...@gmail.com> wrote: > 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 :) > > 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 > _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
