I agree with the point that newcomers will have no idea what EO is (and they should not need to know). It's best to have naming targeted at the newcomer demographic since any developers which are already invested in the community will inherently know which API is being referred to regardless of what we name it.
On Mon, Apr 1, 2019 at 10:34 AM Xavi Artigas <xavierarti...@gmail.com> wrote: > The problem I see with EO is that newcomers don't know what it is, so it > needs to be introduced. > But then again, we could do something similar: *Components (Classic)* > vs *Unified > (EO)*. > I have been envisioning for a while a first page on the Developers section, > clearly split in two, saying: > CHOOSE YOUR POISON > And a paragraph explaining each of the two options. > > On Mon, 1 Apr 2019 at 16:12, Carsten Haitzler <ras...@rasterman.com> > wrote: > > > 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 > _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
