gerlowskija commented on pull request #120: URL: https://github.com/apache/solr/pull/120#issuecomment-858723781
> if we go the path of using the BlobRepository abstraction, the ultimate goal would be to have it be a separate unit :+1: I was assuming a different structure, or maybe reading too much into the current structure of the WIP, but this makes a lot of sense and would do a lot to alleviate both the classpath and documentation concerns I had in mind previously. Of the specific implementations you mentioned, I'm partial to (2) as it seems like a nice middle ground between (1) and (3). It also seems like the approach that'd make it easiest for a user to use BlobRepository in writing their own plugin. But admittedly that's a bit handwavy. Do you have a preference among those options or see other pros/cons there? > it's right on the edge of "are we over-architecting this?". It would of course help to have a third blob client (Azure?) That's definitely the question. I lean I think towards skipping the abstraction until we're in a situation where its value is more clear cut. If someone adds an Azure store next year and more repeated bits of code crop up, we can always add the middle-layer in at that point. But that's just my leaning - if you guys are confident that it'll be better to leave it in, I'm happy to go with that. The BlobIndexInput question might shed light on this too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
