-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iPOPOv2 development #109
Comments
Since I can't commit to follow this development closely, but would like to have a predictable outcome, can we establish clearly what's going to happen here wrt releases and content? i.e. 1 or more releases, what versions (1 and 2?, 2 only?)...requiring which versions of python 2 and 3?), when these are likely to happen, and (eventually) who is going to commit to doing what/when? |
Hi,
|
Hi,
Dear @scottslewis ,
Dear @tcalmant ,
|
Hi,
The shell I/O is handled by the
I think the async sockets will have to be used in the Remote Shell. |
Not sure whether you knew this, but OSGi Remote Services spec v7: https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html Has a section on asynchronous remote services: https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html#d0e1407 Quick summary: A remote service exporter can export a remote service with 'osgi.async' standard service property, and then the client/consumer of this service can use (in java) return types like:
In the RSA impl that I added to iPopo, I added support in the RSA impl for Python class as a possible return type with Python on client: concurrent.futures.Future The effect being that for RSA distribution providers (currently py4j and xmlrpc) if a service is exported with 'osgi.async' intent (as per OSGi spec) then the proxy that gets created on import will return an instance of type concurrent.futures.Future. There's an example of usage of such a proxy injected as self._helloservice here: https://github.com/tcalmant/ipopo/blob/v1/samples/rsa/helloconsumer_xmlrpc.py#L54 Short story: RSA already has support for OSGi Remote Services R7 Async Remote Services. Adding other distribution providers that support the same approach is a relatively simple matter. |
Hi,
Yes, i had a a freudian slip sorry. However I've done some commits to drop the support of python <3.7, but the building upon travis-ci with python 3.8 always fails when it tries to do the discovery fails: To @scottslewis
I totally agree with you |
@Angeloxx92
Sounds good. It might be useful to create an asyncio-based xmlrpc distribution provider (which is currently based on pelix.http.basic). Actually, come to think about it, if a new version of pelix.http.basic based upon asyncio was available it would require no changes at all in the xmlrpc provider to benefit. |
@Angeloxx92 :
Yes, I saw that. I propose we remove the 3.8 tests for now, to focus on the port to 3.7. |
Hi,
to @tcalmant
to @scottslewis
You're right , but maybe we should also add |
Hi @Angeloxx92 . The xmlrpc provider simply turns around and makes http requests after serializing method args (and deserialization, etc on the server side). The current xmlrpc provider (and lots of other things) would benefit from using asyncio to implement the ipopo http service...which is what xmlrpc uses to make the http request/response calls. I don't think there would be any significant benefit to using asyncio on the serialization/deserialization of the args and return values of the xmlrpc provider...since typically this happens in memory. |
Dear @tcalmant @scottslewis, |
Thanks for the news! |
Dear @tcalmant ,
Cause, if I'm on another thread(just to make it simple, call it thread2) and the loop in the main_thread is not running because it has finished to execute To solve this problems there are 2 options:
|
Hi @Angeloxx92 , Losing the compatibility is a big issue, but I'm OK to prototype it, to see where we can go in a full-async version (both in terms of usage possibilities and performances). |
Dear @tcalmant ,
Do you have any idea about it?What should do the compatibility layer? I'm asking this cause I'd like to have all clear in my mind. |
This issue will be used to synchronize with the process of developing iPOPOv2.
I've decided to start working with those bundles:
framework.py
ipv6utils.py
ldapfilter.py
threadpool.py
utilities.py
after that I think we should move to the bundles of the
pelix shell
What do you think? @tcalmant @scottslewis
The text was updated successfully, but these errors were encountered: