OK, so I don't think there's any interest in this beyond me :-( On Wed, Apr 5, 2017 at 1:58 PM, Paul Hammant <p...@hammant.org> wrote:
> I don't really need Fossil to become an application server. I just need > it to handle CRUD over HTTPS on specific resources, and have configurable > permissions for that. Though TH1 scripts exist, I'd not use them, nor > anything that purports to be JSP/ASP application scripting model. I'd not > need them, if I've shifted my application code to JavaScript. > > Just like for CouchDB in a "backend as a service" configuration, *in-house non > financially critical* *applications* are the type of apps that would fit > well. CouchDB implements CORS > <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS> > which all the modern browsers are savvy with too, and that is a partial > answer to XSS/CSRF concerns. > > Anyway - I'd want everything that CouchDB does in the BaaS > <https://martinfowler.com/articles/serverless.html> model, but lose the > query capability if I had to. I'd want to gain security features that CouchDB > doesn't do by default <https://www.google.com/search?q=couchdb+ransomware> > ("AdminParty" > and HTTP *off* by default, HTTPS *on* by default). Why VCS - who > wouldn't want to be able to checkout documents as a set, perform functions > on them, and commit them back as a set, atomically? > > - Paul > > - Paul > > On Tue, Apr 4, 2017 at 2:53 PM, Warren Young <war...@etr-usa.com> wrote: > >> On Apr 4, 2017, at 11:24 AM, Paul Hammant <p...@hammant.org> wrote: >> > >> > > I have little need for such a thing myself, so I’m just throwing this >> idea out >> > > there for anyone who thinks it looks like a good itch to scratch. >> > >> > I do have a need for this class of use. My thread "Fossil as an app >> server" (nearly a week ago on this list) is in the same direction. >> >> Only in the vaguest sort of way. >> >> My idea is just that you should be able to replace the fossil binary as a >> client with a series of HTTP calls, which lets you replace >> fossil-the-client without duplicating all of its internal functionality. >> >> This idea of turning Fossil into a generic application server is off on a >> completely wild tangent from that point. >> >> While thinking about this sort of thing, consider the XSS problem just >> brought up on the mailing list. To me, “generic application server” >> implies multiple independent — possibly mutually-untrusting — applications >> running on a single platform. So, you’d better solve the XSS problem first. >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
