> What I'm suggesting is that we should try to take advantage of this work > to make the right architectural changes to Leo so it can easily handle > *any** storage backend*. > > In the same way, I think we should try to have an abstraction layer from > the underlying SCM, so it can be git or Fossil now, but any other in the > future. *I wish Leo a long live!! * >
I have just seen *right now* that Terry was already suggesting these same ideas some months ago <https://groups.google.com/d/msg/leo-editor/tikOETtl7xs/ZLCD6P6WAgAJ>: I haven't followed the fossil discussion too closely, but I'd argue >> for, rather than adding fossil as a single new data backend, revisiting >> and refreshing (or replacing) Leo's capability of using a "DB" backend, >> with a view to making it a pluggable layer where you might be plugging >> in to fossil or git or sqlite3 or MongoDB etc. etc. >> > Glad to see that! Xavier -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
