On Sunday, October 21, 2018 at 10:37:32 AM UTC-5, Cormac Williams wrote: > I would answer some of your questions with more questions, mainly.
All these questions are reasonable. Here are some preliminary answers. > 1 : Do you want to hang this server on the internet at some point? Not sure what you mean by this. Servers may spawn a new thread for each incoming thread. In any case, we can assume that we'll use a fully-scaled server like Apache. > 2 : What sort of scale do you want in terms of users? Imo, n == 1 is often going to be the limit, for security reasons. Leo looks like an unverifiable cgi script to the server, which means one user (or small, *trusted *group of users) must be *fully* responsible for the damage Leo could cause. It might be possible to host a Leo server in a per-user (or per-small group) virtual machine somewhere, but that's it. I see no way to run a public, unsecured, Leo server. > 3 : What sort of scale do you want in terms of Leo outline size? The same scale as at present. This means that loading a Leo view in a browser won't load the entire xml file, but will only load the parents of presently-selected node. In other words, Leo will use ajax to display the visible part of the outline. > 4 : Do you want to get a database involved rather than serving from an xml file? Good question. I recently thought about this in "plain" Leo. There have been repeated requests for "node history". One could imagine a DB containing old versions. But I just recently saw that *node history would not have commit messages*. Without those messages the "raw stream" of node contents is useless. If the user wants node history, they should use git and be careful to write meaningful commit messages. There is no way for Leo to provide those messages. There is another reason for considering using a DB, namely to support cross-file clones. The likely fatal problem with this is that the entire DB becomes a kind of cache. External files must take precedence. That being so, the DB adds a significant level of complexity, without fundamentally solving the problem. This isn't likely to happen. The third reason to use a DB would be to support huge outlines. There may already be code in Leo to do this. I don't remember. > 5 : I there a multi-user story to be told in terms of using an outline? See the answer to question 2. The answer is yes, but only if all users bear full responsibility for the machine (virtual or not) on which Leo's server is run. > 6 : How much are you prepared to refactor or change code to support the above visions? I am willing to treat the project as essentially a new gui: leo --gui=browser. I will reject any suggestion to fork Leo's code base. That would be the end of Leo, imo. Edward -- 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.
