Moodle
  1. Moodle
  2. MDL-16269

mnet needs to not enforce symmetry

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: MNet
    • Labels:
      None
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      32900

      Description

      1. by application ( eg mahara does not support enrolments so don't offer it)
      2. by service (eg moodle can subscribe to mahara portfolio services but not publish - same for repository)

      also it seems very odd that the language strings for a service go in the plugin that published rpc functions to handle them.

      eg: for pf_out service, many portfolio plugins would publish rpc functions to that service, but the code looks in the language pack of (some) plugin to find them

        Issue Links

          Activity

          Hide
          Penny Leach added a comment -

          same for repository = same but opposite, of course

          Show
          Penny Leach added a comment - same for repository = same but opposite, of course
          Hide
          Penny Leach added a comment -

          the more i look at this it seems like there needs to be a giant refactor.

          in particluar i can't decide the best way to go forward with portfolio services now.... sso_idp publish requires sso_sp subscribe and the reverse is true. but i don't want to have pf_in and pf_out and publish and subscribe for both. just portfolio services, and moodle opts to subscribe to it on mahara.

          this might change later but for now i don't want to go down the route of a major refactor just to get this in, especially since i really don't know the best way to do it properly. so i'm putting in a special case until a group of people can come to a decision about the best way forward for this.

          Show
          Penny Leach added a comment - the more i look at this it seems like there needs to be a giant refactor. in particluar i can't decide the best way to go forward with portfolio services now.... sso_idp publish requires sso_sp subscribe and the reverse is true. but i don't want to have pf_in and pf_out and publish and subscribe for both. just portfolio services, and moodle opts to subscribe to it on mahara. this might change later but for now i don't want to go down the route of a major refactor just to get this in, especially since i really don't know the best way to do it properly. so i'm putting in a special case until a group of people can come to a decision about the best way forward for this.
          Hide
          Peter Bulmer added a comment -

          Reading over this bug, I think I have an understanding of the problem you're reporting.

          If my understanding of what you're reporting is right, then it's worth pointing out that this symmetry assumption is enforced in code - before we can subscribe to a service, we must have the code to provide this service.

          This has been discussed on the mnet forums http://moodle.org/mod/forum/discuss.php?d=102404
          And gets specifically relevant around http://moodle.org/mod/forum/discuss.php?d=102404#p452628

          Show
          Peter Bulmer added a comment - Reading over this bug, I think I have an understanding of the problem you're reporting. If my understanding of what you're reporting is right, then it's worth pointing out that this symmetry assumption is enforced in code - before we can subscribe to a service, we must have the code to provide this service. This has been discussed on the mnet forums http://moodle.org/mod/forum/discuss.php?d=102404 And gets specifically relevant around http://moodle.org/mod/forum/discuss.php?d=102404#p452628
          Hide
          Penny Leach added a comment -

          I don't really understand your comment.

          In general, this bug relates to the mnet roadmap, see http://docs.moodle.org/en/Development:MNET_Roadmap, and the fact that when mnet was developed, symmetry was natural because it was just moodle talking to moodle. with the later addition of the 'application' construct it became slightly less sensible and now as more functionality is being added it's less again.

          I am not relating to the difference between publishing and subscribing I don't think. More the fact that some for some applications whole services don't make sense (eg enrolment doesn't make sense for mahara) as well as the fact that the rpc functions are defined as though they're able to be called in both directions. Eg to be able to call a 'i want to send you a file' rpc function in mahara, I must actually define that function in moodle as an php function, even though it's not actually implemented as such, since it's only called remotely.

          Show
          Penny Leach added a comment - I don't really understand your comment. In general, this bug relates to the mnet roadmap, see http://docs.moodle.org/en/Development:MNET_Roadmap , and the fact that when mnet was developed, symmetry was natural because it was just moodle talking to moodle. with the later addition of the 'application' construct it became slightly less sensible and now as more functionality is being added it's less again. I am not relating to the difference between publishing and subscribing I don't think. More the fact that some for some applications whole services don't make sense (eg enrolment doesn't make sense for mahara) as well as the fact that the rpc functions are defined as though they're able to be called in both directions. Eg to be able to call a 'i want to send you a file' rpc function in mahara, I must actually define that function in moodle as an php function, even though it's not actually implemented as such, since it's only called remotely.
          Hide
          Penny Leach added a comment -

          I was thinking about this more today and it hurt my head. In general I was thinking about what it would take to add a moodle portfolio plugin to moodle.

          And it would want to implement the same functions we have currently... but they would have to live in portfolio/type/moodle/lib.php

          But we already have those functions, in portfolio/type/mahara/lib.php - but they're only the send version.... that is: In order to make permit_rpc_call or whatever that function was allow me to call the mahara xmlrpc methods remotely, it had to be able to find local implementations of them, which is a fallacy (symmetry). So to make that function happy, I created them in the mahara plugin as local (not xmlrpc) functions, but then as soon as I need to implement them as xmlrpc functions (eg in the case that moodle starts being able to be a portfolio server as well as client), we get collision.

          This seems to be all caused by the assumption that server == client - eg, both are moodle, so both have the exact same list of rpc functions available. In the case of portfolio, server and client functions are implemented in different places. Currently send_content_intent and send_content_ready are only implemented as rpc functions in mahara, but the mnet client code in moodle demands them to be able to be found locally.

          Show
          Penny Leach added a comment - I was thinking about this more today and it hurt my head. In general I was thinking about what it would take to add a moodle portfolio plugin to moodle. And it would want to implement the same functions we have currently... but they would have to live in portfolio/type/moodle/lib.php But we already have those functions, in portfolio/type/mahara/lib.php - but they're only the send version.... that is: In order to make permit_rpc_call or whatever that function was allow me to call the mahara xmlrpc methods remotely, it had to be able to find local implementations of them, which is a fallacy (symmetry). So to make that function happy, I created them in the mahara plugin as local (not xmlrpc) functions, but then as soon as I need to implement them as xmlrpc functions (eg in the case that moodle starts being able to be a portfolio server as well as client ), we get collision. This seems to be all caused by the assumption that server == client - eg, both are moodle, so both have the exact same list of rpc functions available. In the case of portfolio, server and client functions are implemented in different places. Currently send_content_intent and send_content_ready are only implemented as rpc functions in mahara , but the mnet client code in moodle demands them to be able to be found locally.
          Hide
          Penny Leach added a comment -

          Closing this as it's largely addressed by the mnet refactor in 2.0 which separates publish and subscribes and puts functions into 2 different tables.

          The language thing is still retarded. I don't really have any good idea about that though.

          Show
          Penny Leach added a comment - Closing this as it's largely addressed by the mnet refactor in 2.0 which separates publish and subscribes and puts functions into 2 different tables. The language thing is still retarded. I don't really have any good idea about that though.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: