Proposed QIIME2 Roadmap

Thanks for expanding on this. I am concerned that this makes the usage
of the software on itself more complicated. Integrating data generated
with qiime1.x or data that was not generated with other packages becomes
a burden as the import step would require a variety of validations and
specifications.

On (Sep-23-14|14:56), Evan Bolyen wrote:
> > +and duplication in defining multiple interfaces. Additionally it will allow
> > +remote execution over a network barrier (this would have been difficult to
> > +achieve with [pyqi](http://pyqi.readthedocs.org/en/latest/)).
> > +
> > +### Workers
> > +Once the _qiime-server_ has received a request via the protocol, it will launch
> > +a worker job to perform the computation. The _qiime-server_ will provide status
> > +updates to clients through the protocol. The worker job will record the results
> > +as an _artifact_ in a database.
> > +
> > +### Database
> > +**Note: This is not intended to be a substitute for the QIIME database
> > +project (QiiTA).** This is a discussion of how data will be organized and stored
> > +internally in QIIME2.
> > +
> > +The database represents a significant departure from the way QIIME currently
> 
> Yes there would be an explicit export step, or in the case of a web interface, likely a right-click download.
> That is a downside to this approach, however it does allow more consistent data management, allows for the provenance of these artifacts to be maintained and reviewed. 
> 
> It is also possible that we could provide the ability to export an entire analysis as a tarball which might look like a well organized output directory in qiime right now.
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/biocore/metoo/pull/4/files#r17942329