On Fri, Oct 20, 2017 at 11:12 AM Leonardo Maccari <[email protected]> wrote:
> > > On 19/10/17 13:30, Federico Capoano wrote: > > >> is it ok with the CSS trick for the properties or we wait to have it >> fixed? >> >> > I'm super busy, so if we want this to be showcased sooner rather than > later is better to do the PR now and fix the issue later. > > > Ok, so I will just do the PR. After the merge please then open an issue so > we keep track of it (I prefer you to do it rather than myself). > > > >> >> >>> >>> >>> Blue circles are important because they tell you visually how big is the >>> part of the network that remains disconnected if you remove one cutpoint, >>> without clicking on the cutpoint (which shows the number of potentially >>> disconnected nodes). So they are not nodes, but their size is important to >>> understand what is happening. maybe we can change the color, or the alpha, >>> or we may change the shape of the cutpoint (from circles to diamonds). >>> I suppose for the latter thing we need to change the library though. >>> >> >> Ok we can play with the alpha. >> >> >> ok, open an issue please? >> >> > which repo? > > > https://github.com/netCommonsEU/netjsongraph.js/tree/robustness_graph > It seems I can't open issues there, so I opened it here: https://github.com/netjson/netjsongraph.js/issues/51 > > >> >> Exactly, my original plan is to process the NetJSON as soon as it is >> fetched/received by openwisp from the source url, and store the modified >> NetJSON graph somewhere in the DB (elaborations on the graph may take some >> time, depending on the graph size, so it is better to store then and only >> serve them when you click on the view). Then add a URL to expose the >> corresponding NetJSON and finally as you say integrate the menu in the >> topology view. >> >> What do you think is better: >> 1 - integrate everything into openwisp-network-topology, modify the >> model for the topology adding another field that determines the type >> ("original", "compressed" and one for all the views we add) >> 2 - keep the library separate (as it is now), do a separate django >> module with its own model? >> > > We should probably do 1, including such a feature in django-netjsongraph, > in a similar fashion as we did for the Snapshot/History feature. Rohith > knows what I'm talking about. > > openwisp-network-topology is a glue layer that integrates > django-netjsongraph into openwisp2 so we won't need to do much there apart > from integrating the new feature into openwisp2. > > > but openwisp-network-topology contains the model for the NetJSON topology > in the DB, right? where do you want the new topologies models be stored? > Main logic is in django-netjsongraph, openwisp-network-topology is a wrapper that integrates it in openwisp2 adding multitenancy to it. Maybe if you take a look ata mode > > I suppose we need to modify the topology view page, so some modifications >> in the topology module are needed even if we go for the second choice. >> > > Yes we need to change the visualiser for sure. > > > ok, this will come after. > > > Is your python module published in pypi yet? I don't see any setup.py file >> so I guess it's not published yet. >> >> not yet, need to take 1/2 decision before. >> > > The module could become part of django-netjsongraph, or it could live > outside and have its own life, immagine being able to build more > visualizations over time without changing django-netjsongraph, that could > be an advantage if you think it will likely happen. > > > it will probably be developed step by step. So yes, I will do a separate > module. > > > So what name would you use in place of visualization/elaboration? > > > visualization fits better I think. > > So the pseudo-roadmap is: > - I do a PR for netjsongraph.js, as is > - you please open two tickets for the alpha and for the properties > Could you remind me the problem regarding CSS hack please? - i do the pipy package for the analyser module > - i start making up my mind on what modifications are needed on > django-netjsongraph and openwisp-network-topology to integrate the view. I > will need some help from you on this again, but then I will make you a > proposal. > > On a different level, I'd like to start matching, wherever possible, the > owners of the nodes with the nodes in the topology. I don't have clear > ideas now on how to do it, so we will need more discussion. > Indeed this needs more discussion because the way to match depends on different variables and we need to find a way that won't make us go crazy. Federico -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
