-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meta Burritos #298
Comments
One use case here is to represent our conceptual Book Packages which consist of 5 distinct resources. We want to distribute the resources as standalone resources but we also want to distribute them as a set. For example, we want to distribute a "Jude Book Package" that includes two translations and 3 related translation helps resources (TA, TN, TW). Here is a potential example using Jude:
|
I prefer a design that would act like a package manager, identifying the burritos that must be present, with no changes to the individual burritos. We could even call it a Burrito Package ... or a Box of Burritos. This is useful, say, for audio+text. This can be distributed in a variety of ways. A zip file could contain other zip files. A directory could contain subdirectories, in a file system or on GitHub. This could be in some database system. |
Minutes from today's discussion: The SB Working Group wonders if this is in scope, or if this should be a separate standard. We also would like to know who the stakeholders are who intend to exchange this data - we should be working with a stakeholder group, as we do for other flavors. It might also make sense to wait for implementation experience before standardizing. We're not saying no, but we have a lot of questions. |
@mandolyte do you have any thoughts on this or a different perspective than what I represented above? |
@jag3773 It seems like a burrito of burritos has the wrong level of granularity, at least for unfoldingWord. Since we manage things by organization, language, and resource type, a burrito that represents that level of granularity makes sense. But a book package is a bit orthogonal to how we manage resources. A book package cuts across and selects a strict subset of each resource type. As in the example above, it is a cross-cutting set of files in each resource that are needed to complete the book of Jude. So whereas a Translation Academy resource (i.e., the "TA" burrito) might contain 200 documents, the subset needed for Jude might be 20 of them. A package manager type of solution would require a burrito per document. This would be trivial if we managed individual documents using a traditional document database, such as MongoDB or similar databases. But as mentioned above, we manage at the resource level using a Git-repo-based approach which doesn't inherently lend itself to managing the lifecyle of individual files. |
@mandolyte As you point out, this isn't really a collection of burritos at all, then. You want a burrito flavor that lets you mix whatever resources you want for a given book, regardless of type. I think you would use a custom burrito flavor (x- flavor) for that and document your format. You don't need us to standardize a new flavor to do that. If we find that different agencies are regularly using this x- flavor to exchange data, then it is a candidate for standardization in a future version of SB. |
Even if this isn't @mandolyte's use case, we do see a need for a way to declare a set of burritos that must be present, similar to a package manager in JavaScript, where a single burrito is analogous to a JavaScript library and the package manager uses a manifest to ensure that they are all present. For instance, in NPM, this is package.json. Note that this may include multiple burritos of the same flavor, with different metadata, and there may be identical file names and paths in these burritos. |
We need them! More description to come...
The text was updated successfully, but these errors were encountered: