On Tue, 22 Jan 2013 10:48:04 +0900 Isaku Yamahata <[email protected]> wrote:
> I'd like to discuss its design before going into reviewing coding detail. > > Can we split event source/sink and event loop from ryuapp? > So single ryuapp can define multiple event sources. And more flexible > event source/sink connection is possible. Actually (unmerged) > gre_tunnel app defines multiple event source. No need. The current code already can handle multiple event sources. > Introducing register_handler/observer to RyuApp will introduce > dependency between RyuApps. It means that when loading RyuApp dynamically, > loading order will be important. Although I think "bricks" is your answer to Doesn't matter since event observerer registration is done after starting Ryuapps. See the changes to ryu_app.py It's hacky for the compatibility. > app-dependency, how about something like hub? > publisher -> hub -> subscriber > > State change (set_state) doesn't seem work. > dpset.DPSet.dispatcher_change() isn't called when the dispatcher is changed > to dead. Since catching state change in this way is error-prone, it would > be safer to introduce state change event. OpenFlow Service already support state change event. set_state() changes only the state of OpenFlow Servce internally. > event_dumper will be broken. It would be necessary to list all event source > and to subscribe all event. Yeah, but I don't think it's a problem. ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
