Okay, I've heard back and it seems like current ecore-con behavior matches expected behavior so I have no more blockers there.
On Mon, Apr 10, 2017 at 2:26 PM Mike Blumenkrantz < [email protected]> wrote: > 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
