search

figshare / Total-Impact

Uncovering the invisible impacts of your research.
http://total-impact.org
Other
43 stars 4 forks source link

Send artifacts IDs only to proper plugins #7

Closed cdparra closed 13 years ago

cdparra commented 13 years ago

When sending IDs to plugins, pre-filter them and send each to the plugin that can produce an output for the ID.

For example, DOIs shouldn't be sent to Slideshare plugin.

hpiwowar commented 13 years ago

Yes, this would decrease unnecessary network traffic. That said, it makes it more complex to add a new plugin. Because of that, until we discover that our amount of network traffic is a problem, I'm thinking it works best to let the plugins do the filtering themselves....

cameronneylon commented 13 years ago

Strictly speaking I guess the plugins should register with the core both what IDs they can take (via REGEX perhaps?) as well as what they will be (trying to) return. Would defining the plugin interface help with the security issues you note? Will get much more participation and plugin contribution if python is available in my opinion.

On 15 May 2011, at 12:02, cdparra wrote:

When sending IDs to plugins, pre-filter them and send each to the plugin that can produce an output for the ID.

For example, DOIs shouldn't be sent to Slideshare plugin.

Reply to this email directly or view it on GitHub: https://github.com/mhahnel/Total-Impact/issues/7

hpiwowar commented 13 years ago

The "registering" idea is a good one, and you are right, if plugins registered with a regex it would address my concern.

fwiw: we imagine the plugins can always be written in Python (or anything else), no worries there. Right now we have a PHP "plugin handler" that manages the web service api and calls the currently-implemented plugin code that does the metric gathering. This web service code was written in PHP just to be speedy in hackathon implementation, and it is the way that PHP calls the python handler guts that is suboptimal. Future plugins could be written in parallel with these, or -- more extensibly -- handle their own web service api and run on any machine anywhere.

jasonpriem commented 13 years ago

yep, I agree heather. Although I'm still unconvinced that we should filter before sending to plugins. "What things can Mendeley help us with?" is, in my mind, a question that wants to be answered by the Mendeley plugin. The idea is to keep everything about a given source sequestered in the plugin. That way, when these external APIs change--and they do, a lot--there's exactly one thing that fails tests, and one place to fix it.

cdparra commented 13 years ago

Agree that each plugin should deal to filter out what ids it can't process by answering with a proper "No Content" alike answer.

On Mon, May 16, 2011 at 2:05 AM, jasonpriem < reply@reply.github.com>wrote:

yep, I agree heather. Although I'm still unconvinced that we should filter before sending to plugins. "What things can Mendeley help us with?" is, in my mind, a question that wants to be answered by the Mendeley plugin. The idea is to keep everything about a given source sequestered in the plugin. That way, when these external APIs change--and they do, a lot--there's exactly one thing that fails tests, and one place to fix it.

Reply to this email directly or view it on GitHub: https://github.com/mhahnel/Total-Impact/issues/7#comment_1168012

Cristhian Parra

cameronneylon commented 13 years ago

I would say that either the plugin should filter or it should register a filter with the core system. In the first instance easiest to do this in the plugin but I'd suggest encouraging that there be a standard routine "filter_id" or similar so we can back it out into a registration system later if we decide to.

Cheers

Cameron

On 16 May 2011, at 10:35, cdparra wrote:

Agree that each plugin should deal to filter out what ids it can't process by answering with a proper "No Content" alike answer.

On Mon, May 16, 2011 at 2:05 AM, jasonpriem < reply@reply.github.com>wrote:

yep, I agree heather. Although I'm still unconvinced that we should filter before sending to plugins. "What things can Mendeley help us with?" is, in my mind, a question that wants to be answered by the Mendeley plugin. The idea is to keep everything about a given source sequestered in the plugin. That way, when these external APIs change--and they do, a lot--there's exactly one thing that fails tests, and one place to fix it.

Reply to this email directly or view it on GitHub: https://github.com/mhahnel/Total-Impact/issues/7#comment_1168012

Cristhian Parra

Reply to this email directly or view it on GitHub: https://github.com/mhahnel/Total-Impact/issues/7#comment_1172440

jasonpriem commented 13 years ago

Ok, seems we're agreed that, at least in the short to medium term, filtering should be handled by the plugins. We can let plugins push filtering upstream if network issues become a problem.