tscv11 has been bringing up the idea of BLOBs in Leo, something that's come up before but never moved forward.
Binary Large OBject (BLOB) is the term used by databases for binary assets which don't fit in any of the regular text / int / real number kind of fields. For Leo handling BLOBs would mean managing a collection of PDF / SVG / bitmap (image formats) / spreadsheet / etc. kind of files, with the option to view them (possibly in a pane in Leo, but in an external viewer is fine too), edit them (most likely in an external app.), store the updated version, etc. Rather than a single collection of BLOBs, there should be a list of collections of BLOBs (i.e. a @settings -> @data node). Each blob would have an ID, which would be a simple string, which can be anything the user wants, so if you want to include slashes and think of it was a virtual file system with folders, you can. We'd also need some kind of a file type info. to select the right viewers / editors. Base level of the API would be something like g.blob.view(id) g.blob.edit(id) g.blob.add(id, filepath) g.blob.delete(id) but we could also have a list of blobs associated with each node, in v.u, and some kind of in body link like blob://myblob-ID, etc. tscv11 has been working on storing BLOBs in sqlite. I think we could support multiple BLOB collection storage backends, so the @data node listing BLOB collections might look like: sqlite:/path/to/some/sqlite.db dir:/path/to/a/directory/hierarchy/containing/blobs zip:/path/to/a/zip/file/containing/blobs Backends that can store multiple BLOBs in one file are nice, like sqlite, zipfile, etc. Because then you only need to copy one file around. Such formats may need some sort of g.blob.repack(collection_id) to handle addition of updated values for BLOBs. I'm not sure how sqlite and Python's zipfile actually handle updates, but Python's tarfile I think would just append the new values, making the file grow ever larger. Sqlite would have the additional benefit that it could be combined with Vitalije's sqlite outline format work to store the outline and the BLOBs in the same file - it's always nice if everything can be transported in a single file. One reason I'd like to support multiple collection formats and not just sqlite is that I'm not sure sqlite's BLOB storage is the most efficient space wise. I made a simple test adding /usr/bin/* to a sqlite DB and ~760 Mb of files created a 1.2 Gb DB file. Also a dir: based backend would be good for pointing into a DropBox kind of folder, and designing the API to allow different backends would allow for cloud storage etc. Thoughts? Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
