<dkubb>
mbj: feel free to fork it and add more comments. I'll aggregate things, and then expand the detail so we can put together a proper roadmap
<mbj>
dkubb: Currently I have no additions. But I keep it in mind.
<mbj>
dkubb: thx!
<dkubb>
mbj: I'll figure out the dependencies between things, and set a priority too.. which of course you and snusnu can have input on
<mbj>
sure
<dkubb>
I just want to have something concrete to begin discussions
<dkubb>
we also need to design a parallel track beside the core development
<dkubb>
something for people to get started with things
<mbj>
plugins / integrations etc?
<dkubb>
it's unlikely someone can jump right into mapper dev, even someone really skilled
<dkubb>
yeah, support extraction, new mutations, fuzzing
<mbj>
It took us years to find a "design". and its still uneasy to explain to outsiders.
<mbj>
I'd love we can find someone doing that nasty *-rails stuff.
<dkubb>
yeah, what I would like to see is contributions to the supporting infrastructure first, and gradually working them into the core stuff
<mbj>
Where I think we need {rom,mutant}-rails at least.
<dkubb>
yeah, that would help
<dkubb>
so you do have something to help add :)
<mbj>
heh
<dkubb>
feel free to add that to your fork. I'll keep the main one up to date and merge in yours and snusnu's suggestions
<mbj>
Mhh, for me it does not belong on the roadmap.
<mbj>
dkubb: Its to "framework specific".
<mbj>
And does not block rom in any way.
<dkubb>
mbj: you can add another category like "support" and put it under that
<dkubb>
mbj: like I said, I want to have two tracks
<mbj>
dkubb: good point.
<dkubb>
mbj: so many people have asked me where to start helping, and I can't answer them because the core track requires too much foundational knowledge
<dkubb>
mbj: whereas extracting support libs, and other stuff can help give them exposure to the process first
<mbj>
dkubb: Help could also be testing.
<mbj>
dkubb: It would be perfect to get more real world feedback.
<mbj>
dkubb: And we could need some OSS funding. Yeah that old topic again ;)
<dkubb>
people coming into core dev would have to both understand the process *and* understand the architecture, which is too much to ask
mbj has quit [Quit: leaving]
<postmodern>
related to our previous discussions about creating mapping layers from DSL to some other representation
<postmodern>
im back again working on a DataMapper like pattern for Ronin's cached metadata using DM1
<postmodern>
provide a basic declarative DSL at the class-level for annotating the metadata
<postmodern>
then map certain metadata to certain DM1 models for caching
<postmodern>
once rom becomes usable, it would essentially replace my custom DM1 mapper layer
<dkubb>
postmodern: interesting. I'd love to see what you come up with
<postmodern>
dkubb, yeah, still working out the details
<postmodern>
dkubb, like where to store/define the metadata models
<postmodern>
dkubb, considering using your nested anonymous class trick