Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Chris Drexler]

> On Windows (which is what the "non-technical" people will probably be
> running) you cannot write to an executable file while it is running.

Again correct: we are mainly talking about Windows where an executable
cannot write to itself --> read-only it must be.

That brings us to the update scenarios Stephan mentioned:
* there cannot be an automatic "self-update"  of this self-contained
repository/exe
  (which would be a very nice feature, but seems fine for my UC)
* updates need to be done via an external fossil.exe via explicit push
to that
  self-contained repo/exe, which would be fine for me as wellas this
would then be
  done by the "technical" staff

Regarding the problem areas mentioned below:

>  (1) The server keeps running until the user shuts it down.

Seems to be ok as ...

>  (2) ... Windows will pop up a DOS box ...

... and even non-technical people can click the [x] close button on this
dos-box
window.

So I see the dos-box to be a feature rather than a problem  :-).

AND: if this is really going to be a feature within fossil I'd go with a
least possible
risk/impact version of it. IMHO That would really just include the
read-only access
via "fossil ui" and even there I would make the usage of an attached
repo explicit as we'd need the ui cmd-line option anyway and as such we
won't change
the behavior for others that don't want/need it.

e.g. "fossil ui --self"

Chris


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Richard Hipp]

On 5/12/18, Chris Drexler  wrote:
>
> OR (my use case now) I can provide one executable on that they start
> locally
> on their computer and point their web-browser to the localhost url. BAM
> documentation including version information. no handling of individual
> files
> no export, no version mix-up. And I can use all the nice features of fossil
> to render the embedded docs and serve static files.

On Windows (which is what the "non-technical" people will probably be
running) you cannot write to an executable file while it is running.
Hence, the appended Fossil repository will need to be read-only.  But,
for your use case, maybe that will be ok.

To make this useful, we'd want to rig up Fossil to check for an
appended repo when it is started with no arguments and automatically
runs "fossil ui $self" if it finds an appended repo.  That way, when
the non-user double-clicks on the "drexler-reports.exe" icon, the
starting web screen immediately pops up in their preferred browser.

Problem areas:

(1) The server keeps running until the user shuts it down.  And there
is no way to shut it down from the web interface.  And even if there
was a way to close the server from the web interface, the user might
just close their web browser and that would still leave the background
server running.

(2) When you double-click on the "drexler-reports.exe" icon (which is
really "fossil.exe" with the repo appended) Windows will pop up a DOS
box for you.  Converting "fossil.exe" into a windows program that does
not automatically start a DOS box involves magic that I am not up on.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Stephan Beal]

On Sat, May 12, 2018 at 5:35 PM, Chris Drexler 
wrote:

> Does this make sense? At least from a workflow perspective?
>

Personally, i don't think so ;), but i tend to be admittedly pessimistic
when it comes to "oddball setups".

How do you expect to sync changes with such users? How do you expect to
handle multiple copies of the binary (i.e. multiple copies of the repo) on
each user's machine? At some point they'll overwrite one fossil bin with
another one, thereby losing any changes they had made to the first.
Upgrading the binary should not destroy any associated data, and that's
exactly what will happen if all users aren't 100% careful with their copies
of the binary.

If it's truly static and users only have read-only access to the data, then
it's far simpler for them to forego the binary altogether and use
http://your-IP to connect to a central copy running on your workstation.

"Can of worms" is what immediately comes to mind. An interesting idea, i
admit, but "can of worms" trumps "interesting" for me.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Chris Drexler]

Hi,

you are perfectly right with your assessment, I had other/additional use
cases
in mind targeting more non-developers.

Just to explain: e.g. developer/technical people are doing an analysis and
generate code as well as results. With fossil that's easy to keep together
and the (mostly, in my case) markdown files with images are in the same repo
as the code that are used to generate these results.

In order to provide this information to "other" people I need to export the
docs into another format (html, pdf) and version it accordingly so that I
can trace from which version the doc has been generated..

OR (my use case now) I can provide one executable on that they start locally
on their computer and point their web-browser to the localhost url. BAM
documentation including version information. no handling of individual files
no export, no version mix-up. And I can use all the nice features of fossil
to render the embedded docs and serve static files.

Maybe this is very special for my environment (big company, various level
of skills involved within such an analysis).

I agree that a full fledged dev or server use case has lots of pitfalls with
this AppendVFS, but that was not what I had in mind. I guess even read-only
access to this attached repo would be fine for my UC. Maybe this could even
alleviate some of the problems that you mentioned below.

So I did not consider CGI, server side hosting, various upgrade
scenarios,etc

Does this make sense? At least from a workflow perspective?

Thanks
chris


Am 12.05.2018 um 14:09 schrieb Stephan Beal:
> On Sat, May 12, 2018 at 1:51 PM, Chris Drexler
> > wrote:
>
> Thoughts? If someone could hint me at the right place within the
> fossil code I could also try to provide an implementation.
>
>
> IMO: every clone would not have that feature, so it would seem (to me)
> to be of limited use. The only benefit would be that you only have 1
> file, instead of 2, to copy to the remote server. (If you build your
> binary on that server, even that benefit is lost.) If your server is
> upgraded in a way which becomes incompatible with your fossil binary
> (incompatible SSL upgrade or (possibly) libc upgrade), you're hosed:
> the repo is then locked inside a binary file which other fossil
> binaries cannot read. (i've had hoster-side OS upgrades break my CGI
> binaries before, though i don't think i've seen it happen to my fossil
> binaries.)
>
> Another point to consider: the binary itself would have to be writable
> by the web server process, which opens up a potential security hole.
> In my experience, Apache runs CGI scripts as the account holder (as
> opposed to some generic 'www' user), and that account holder already
> has write access to the binary. However, i make my CGI bins read-only,
> even to myself, "just in case" (because one too many wordpress
> vulnerabilities have made me paranoid in that regard).
>
> It sounds to me like such a feature is tantamount to walking a
> minefield in which any given mine could leave you unable to access the
> repository data.
>
> Just my opinion, of course. It may very well work out fine for you.
>
> -- 
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct
> of those who insist on a perfect world, freedom will have to do." --
> Bigby Wolf
>
>
> ___
> 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

Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Stephan Beal]

On Sat, May 12, 2018 at 1:51 PM, Chris Drexler 
wrote:

> Thoughts? If someone could hint me at the right place within the
> fossil code I could also try to provide an implementation.
>

IMO: every clone would not have that feature, so it would seem (to me) to
be of limited use. The only benefit would be that you only have 1 file,
instead of 2, to copy to the remote server. (If you build your binary on
that server, even that benefit is lost.) If your server is upgraded in a
way which becomes incompatible with your fossil binary (incompatible SSL
upgrade or (possibly) libc upgrade), you're hosed: the repo is then locked
inside a binary file which other fossil binaries cannot read. (i've had
hoster-side OS upgrades break my CGI binaries before, though i don't think
i've seen it happen to my fossil binaries.)

Another point to consider: the binary itself would have to be writable by
the web server process, which opens up a potential security hole. In my
experience, Apache runs CGI scripts as the account holder (as opposed to
some generic 'www' user), and that account holder already has write access
to the binary. However, i make my CGI bins read-only, even to myself, "just
in case" (because one too many wordpress vulnerabilities have made me
paranoid in that regard).

It sounds to me like such a feature is tantamount to walking a minefield in
which any given mine could leave you unable to access the repository data.

Just my opinion, of course. It may very well work out fine for you.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users