Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen_developers] Architecture Update

Expand Messages
  • Martijn Verburg
    Hi Tom, I m afraid I ve only been able to skim over these quickly, but here are some quick thoughts: 1.) I m almost regretting the choice of Spring for our DI
    Message 1 of 4 , Jan 21, 2013
    View Source
    • 0 Attachment
      Hi Tom,

      I'm afraid I've only been able to skim over these quickly, but here are some quick thoughts:

      1.) I'm almost regretting the choice of Spring for our DI implementation.  It's a fairly heavy-weight lib these days and since we're only using it's DI/IoC - its ecosystem advantage is rendered mute.  I wonder if it's not too late to replace Spring with Guice or PicoContainer

      2.) CDOM, Facets and their interactions are starting to look very much like a Graph database to me.  Might be possible to leverage something like NeoJ to reduce the plumbing that we build?

      3.) I love the coreview mini project - although we as developers have some power over our debuggers, end users do not and giving us another investigation tool is great.

      4.) I agree firmly with the design goals of the BONUS redesign.  I'm not deep enough into PCGen code to comment sensibly on the proposed implementation except to say that I agree that this is a very TEMPLATE like set of user stories.

      K


      On 19 January 2013 01:52, thpr <thpr@...> wrote:
       

      I have put on the wiki a first draft of a 1Q13 Architecture update:
      http://wiki.pcgen.org/Architecture_Update_1Q2013

      ...and some thoughts on Bonus Subsystem redesign:
      http://wiki.pcgen.org/Bonus_Subsystem_Design

      Feedback welcomed.

      TP.


    • Chris Dolan
      Selfishly, I agree with #1. Spring is a nightmare on Android because it digs down to the .class file way too often. Even SpringSource s own
      Message 2 of 4 , Jan 21, 2013
      View Source
      • 0 Attachment
        Selfishly, I agree with #1. Spring is a nightmare on Android because it
        digs down to the .class file way too often. Even SpringSource's own
        spring-android-core.jar supports only a subset of the functionality PCGen
        uses and is not compatible with spring-beans.jar. So, I'm already looking
        at (experimentally) replacing the SpringWorker in my own code base.

        Chris


        On Mon, January 21, 2013 11:33 am, Martijn Verburg wrote:
        > Hi Tom,
        >
        > I'm afraid I've only been able to skim over these quickly, but here are
        > some quick thoughts:
        >
        > 1.) I'm almost regretting the choice of Spring for our DI implementation.
        > It's a fairly heavy-weight lib these days and since we're only using it's
        > DI/IoC - its ecosystem advantage is rendered mute. I wonder if it's not
        > too late to replace Spring with Guice or PicoContainer
        >
        > 2.) CDOM, Facets and their interactions are starting to look very much
        > like
        > a Graph database to me. Might be possible to leverage something like NeoJ
        > to reduce the plumbing that we build?
        >
        > 3.) I love the coreview mini project - although we as developers have some
        > power over our debuggers, end users do not and giving us another
        > investigation tool is great.
        >
        > 4.) I agree firmly with the design goals of the BONUS redesign. I'm not
        > deep enough into PCGen code to comment sensibly on the proposed
        > implementation except to say that I agree that this is a very TEMPLATE
        > like
        > set of user stories.
        >
        > K
        >
        >
        > On 19 January 2013 01:52, thpr <thpr@...> wrote:
        >
        >> **
        >>
        >>
        >> I have put on the wiki a first draft of a 1Q13 Architecture update:
        >> http://wiki.pcgen.org/Architecture_Update_1Q2013
        >>
        >> ...and some thoughts on Bonus Subsystem redesign:
        >> http://wiki.pcgen.org/Bonus_Subsystem_Design
        >>
        >> Feedback welcomed.
        >>
        >> TP.
        >>
        >>
        >>
        >
      • thpr
        ... I m hesitant given the work required and that there are things I would like to do with Spring in the future (once they become more obvious that we need
        Message 3 of 4 , Jan 21, 2013
        View Source
        • 0 Attachment
          --- In pcgen_developers@yahoogroups.com, Martijn Verburg wrote:
          > 1.) I'm almost regretting the choice of Spring for our DI implementation.
          > It's a fairly heavy-weight lib these days and since we're only using it's
          > DI/IoC - its ecosystem advantage is rendered mute. I wonder if it's not
          > too late to replace Spring with Guice or PicoContainer

          I'm hesitant given the work required and that there are things I would like to do with Spring in the future (once they become "more obvious" that we need to do them). As best I understand those things are hard and/or impossible under Guice or PicoContainer. If we are going to swap to Guice or PicoContainer, some of those avenues get cut off and we thus need to have those discussions now and fully understand the implications. I'm also not sure the churn is worth it given that we have Spring working. I'm not all that interested in a new shiny for the sake of a new shiny - that just drains our limited development resources. I'm interested in what is broken or what the new things enable. What part of Spring is really a problem? (our overall code dwarfs Spring)

          > 2.) CDOM, Facets and their interactions are starting to look very much like
          > a Graph database to me. Might be possible to leverage something like NeoJ
          > to reduce the plumbing that we build?

          The original CDOM architecture spec pointed out the graph characteristic a long time ago, so seeing that shouldn't be a surprise :)

          Neo4j (as best I can tell) is designed for storing information that is in a graph. That "heavy lifting", if you can call it that, has already been done in the original cdom branch. I wrote that graph code almost a decade ago for rpg-mapgen. While storing the data in a graph was the original proposal for CDOM, that is not what we have implemented. The storage right now is fully distributed in the facets (I happen to like this better than the graph for a number of reasons that I'll skip for the moment). The facets are connected in a graph, but not in the way Neo4j seems to think. (It thinks in relationships between objects, our links are event pathways). Neo4j seems to be about traversing a graph to answer questions (more akin to the original CDOM proposal), not a set of events moving through a graph, which is really what our "graph" is doing right now.

          That's not to say some meta information about our facet setup wouldn't be useful - the coreview project got put into pcgen.cdom.meta for a reason - but I'm not sure if Neo4j would be worth the trouble. (Right now I don't see it buying us anything or helping us build that metadata).

          It may also be possible to "turn Neo4j inside out" and use it in a non-traditional way, but I'm afraid that would look more like code obfuscation than leveraging an existing framework.


          > 3.) I love the coreview mini project

          Thanks.

          TP.
        Your message has been successfully submitted and would be delivered to recipients shortly.