Just wanted to point everyone at some (fairly extensive) changes I'm proposing to integrate into the trunk at some point in the near future. Aside from hopefully speeding things up to the point where you actually might want to use melkjug, these changes are largely not user facing and should mainly be of interest to devs working on the core.
This is currently a not fully functional work in progress, but you can have a look-see by substituting "opt.pips" for "trunk.pips" in the dev guide instructions: http://trac.openplans.org/melkjug/wiki/DevelopmentGuide . I encourage anyone with the inclination to at least try checking it out and running the tests in the melk.model package and report success or failure in doing so.
The most extensive changes are on the "opt" branch of the melk.model and melk.selection packages. Changes to other packages are mainly focused on adapting to those changes and fusion / elimination of several other packages.
For the broadest overview of what this rendition of melk.model looks like, have a peek at this diagram http://www.openplans.org/projects/melkjug/attachments/melk-model.pdf or directly at some of the python interfaces that make it up http://trac.openplans.org/melkjug/browser/melk.model/branches/opt/melk/model/interfaces.py .
The SQL implementation of this model eschews a request-time-search behavior in favor of literal periodic internal aggregation to determine the articles that are in a user's jug as it's primary request-time speedup (though I believe there is nothing that requires this be the case in all implementations). Picking the best articles out of that is still done at request time and preserves the behavior of posting in a mixing spec to affect anonymous temporary adjustments to another user's jug. Much of the article scoring is moved from a background process into a request-time calculation for relevant articles only (though there is support for caching to achieve the earlier pre-calculated behavior where/when it is warranted) Also notable is that the treatment of anonymous temporary 'try it' users is unified with 'normal' signed-up users as opposed to being sort of a different model stored in the session. Questions about any of these are more than welcome.
Lastly, the model supersedes melk.silo.* packages with a facade built over it's own interfaces that implements (most of) the old silo interface. That means currently melk.silo.potato, the CouchDB silo is excluded -- but I think much of the existing code can be either ported or integrated as-is using a suitable adapter. Moreover, I believe ultimately these changes will make it easier to provide unified (or even perhaps mixed) backends for the entire system (not just the silo) on top of CouchDB and other systems. I am interested in hearing about any potential snags in doing so that are not obvious to me or constrictions on implementation of backends that the interfaces impose.
- Luke -- Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1233956780694 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
