Luke Tucker
2009-02-06 21:46:13 UTC
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 melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.
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 melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.