Details
-
Type: Task
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Datamodel, Dev and Dep, file format issue
-
Labels:None
-
Epic Link:
Description
The current paradigm for writing an alignment file from Jalview is to create a new set of SequenceI + AlignmentAnnotation objects wholly containing the sequences + annotation to be output. This happens either via AlignmentView objects or alignment objects plus strings specifying 'visible' regions of sequences.
Ideally, parsers should be able to take a lightweight set of references specifying the regions of an alignment to be output. Currently, parsers are hardwired to work with a vector of SequenceI objects plus annotation - refactoring is needed to allow proxy classes to be used such as the AlignmentView/SequenceCigar objects, or even the AlignViewport object itself (if thread safety allows it), to avoid duplicating/triplicating the memory needed when exporting alignment data.
Ideally, parsers should be able to take a lightweight set of references specifying the regions of an alignment to be output. Currently, parsers are hardwired to work with a vector of SequenceI objects plus annotation - refactoring is needed to allow proxy classes to be used such as the AlignmentView/SequenceCigar objects, or even the AlignViewport object itself (if thread safety allows it), to avoid duplicating/triplicating the memory needed when exporting alignment data.
Attachments
Issue Links
- blocks
-
JAL-1760 Flatfile output does not restore hidden sequences
- Closed