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

Reply via email to