I no longer do development or maintain azy, that's been taken over by some others on the list who work more closely with it and ship it in production. They actually still use EFL 1.7 with selective backports since we have no way to configure a "server" build and were--for some reason that I don't recall--violently opposed to the idea of adding one. As a result, I don't imagine there's any desire to do any conversions for azy internals, at least not unless we have an interest in working with them to provide an upgrade path for their EFL usage.
On Mon, Apr 10, 2017 at 11:26 AM Gustavo Sverzut Barbieri < [email protected]> wrote: > On Mon, Apr 10, 2017 at 11:48 AM, Mike Blumenkrantz > <[email protected]> wrote: > > I can confirm that the specific case cited in that ticket is now fixed, > but > > I ran some other tests from azy and they are now failing when they did > not > > used to fail. I've requested some regression testing from another azy > user, > > and I hope to have these results within a day or so. > > okay, let me know the test. > > > > On a side note, I don't think it's reasonable to say that the behavioral > > discrepancies here are "legacy" and thus imply that it's a corner case. > > This is, afaik, the most widely deployed means of using ecore-con, and it > > is currently used/shipped on thousands of devices. > > during efl.net development I changed the whole working model, > splitting out the buffering to an independent component that could be > used by non-network stuff (like: stdin, stdout, stderr, files, pipes, > exec...), focusing on a single synchronous read/write API that is > similar to read(2) and write(2) + select(2). These independent > components such as efl.io.copier will monitor readiness and read/write > data, caring about buffers sizes, line delimiter, etc. It also makes > uniform access to all technologies, be websocket, http, udp, tcp, > unix, file... > > Then the ecore_con API was recreated on top of that as > ecore_con_legacy.c. The test suite passed, human inspection (mine) > says it respects what was described in Ecore_Con.h... but there are > some subtle behavior that was allowed yet not tested/documented. > > This old API will be deprecated one Eo gets out of beta, thus the term > "legacy". > > Whenever that happens, ping me so I can help to convert Azy to the new > API and Eo in general... during the Efl.Net development we settled on > some items, like make all errors Eina_Error (ie: you have > Azy_Client_Error)... That's if you want to expose an Eo API, of > course.. in every case, during Azy port to new API you may have some > ideas on offering some way to integrate high level protocol parsers on > top of Efl.Io.Buffered_Stream > > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 <+55%2016%2099354-9890> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
