Zim-desktop-wiki: Google Drive backend

[smaudet]

All that would be necessary is to implement a fs that implement stuff in newfs, as well as hook in various parts of code the integrations.

I think the biggest issue I have come across so far is what to do about the sqlite database which is being used to index the notebook pages - it might be good to have some way of resolving index changes and/or locking files being edited in google drive, while allowing everybody to access and read/write.

Further, sections could be locked for read/write access by the drives' own controls.

I have code that is half working on this front, which is reading and writing pages and notebooks.

[Self-Perfection]

What are benefits of implementing Google Drive inside Zim? It seems using external tool to mount Google Drive would be much more convenient.

[smaudet]

More seamless integration, is the main reason.

I'd rather download a keyfile for Zim, and it just work, than need to:

1) Install google drive for my platform (assuming it even exists)
2) Login on all my computers
3) Manage which folders to sync or not sync per computer/device
4) Or generally worry at all about a bunch of third party tools (filesystem libraries + external apis), just to use a notebook on a cloud service.

It also generally enhances Zim's capabilities - such that the medium to support networked notebooks is less relevant (google drive today, box tomorrow, random thing in the future).

Looking, even further and future facing, if Zim doesn't care about where its files are, just that it has some library to access them, it becomes even less important that Zim edits them. If anybody can edit your wiki with the right set of api calls, then Zim no more than a library that knows how to call an api for an expected result.

I see this ultimate end goal as a good thing - the more things that use Zim-like syntax (and exhibit zim-like behavior), the better.

I'm sure you've heard of Markdown, by now - why do you think it was so successful? Not because the original guy who built markdown was such a genius, but because the format was so simple.

That being said, Zim is many things above and beyond what Markdown. It would be fantastic I think to make Zim into such a standard.

[smaudet]

Note: It appears somebody deleted their comments here...I've removed the part that they were I think trying to troll or something. The rest of it I think stands.

The direct integration to google drive could theoretically be throw away (change api, change license agreement, although I don't see either thing becoming a serious problem for a while), but the changes to the zim-core itself are not. There are many things I had to do in the project so far to make the newfs part of Zim not a meaningless abstraction but rather something which actually works well.

In fact, I chose Google Drive because it was the easiest for me to implement (I already know the google drive api well as I've used it for a couple other projects of mine, and I'm familiar with that platform) and because it is one of the most popular cloud drives out there (least like to disappear next year), but I want it to be able to support not just Google Drive but the rest of the gamut. My implementation has some google-specific things at the moment, yes, but they are already well abstracted by the existing newfs interface. All that has to be fixed is some relatively minor loading problems within the core app.

As for being 'close to' DocuWiki, well, that's not really the same, is it? I don't mind an adapter for Zim to read/write/export DocuWiki, but I somehow don't think that it is the same thing, not only because it isn't Zim, but support for DocuWiki syntax can change whenever DocuWiki decides they want to do something different.

[bgutter]

Isn't the whole point of Zim that it runs on the local filesystem with a file-format that's readable and manageable outside of the editor?

I would think that you could cloudify Zim fairly well with FUSE or sync clients for whatever cloud provider you're using. Pulling in many different filesystem backends sounds very bloaty and not very unixy.

[smaudet]

@bgutter do you actually have a technical objection or are you just given illogical 'shivers' here?

FUSE or sync clients are far bigger bloat requiring a completely different stack to handle. If you want 'unixy', don't use zim, it has plugins.

To be frank I'm a bit disgusted by the community response so far - I've put work in so far, this is not harmful, this can only help - and I'm met with all manner of voodoo nonsense about how it makes people 'feel' bad...

Kindly, get over your outdated feelings and/or please, actually provide some real feedback or don't provide any at all.

FUSE/filesystems are a garbage 'solution' - they're not a solution - they're an admission at best the software is not capable, at worst that you have a mental problem seeing that they're not simpler but more complicated and ultimately, just a horrible solution.

[bgutter]

Scope creep is a technical objection. I don't find it illogical, obviously, but you're free to your opinion. It just seems like a very odd feature request, when existing tools can produce a better solution.

I also do not see how use of FUSE or a sync client on a deployed system would bloat Zim, since they would be used beyond Zim's purview. Further, I don't think extensibility through plugins contradicts the unix philosophy. But either way, it's all neither here nor there. Interested to see what the Zim devs think about it.

[smaudet]

I don't see on the Zim wiki site where is states its mission objective is to be local only (which would be the only reason I could see for it being 'scope creep').

The bloat is that I have to manage some FUSE or sync client at all. What if I'm on windows, mac and linux? Now I have to manage three different solutions potentially for the one client? How is this a 'better solution'?

Its not, offloading the work to a middle-tier stack is a cop-out at best, and poor design at worst. Not to mention, there are design flaws inherent with depending on such a stack. You cannot control what happens to the fs so you are at the whim of any of the many layers of OS/FUSE/sync layer, you cannot control the client, period. There are many technical reasons why this is not ideal.

And, yes, plugins violate the unixy standard - if a program is supposed to do one thing, and one thing well, a plugin is a direct violation of this - it now provides an environment for a another program to interact, with only itself, to do multiple things. The unixy approach would be to offload any and all processing to another distinct program, as you want to do with FUSE.

I would like to further point out, the goal of Zim is not to only function on Unixy systems.

[bgutter]

Extensibility does not really break the unix philosophy -- here's a well-written Quora comment explaining it in the context of emacs. It's quite compatible once you're past the semantics.

Don't all high-level applications deal with this issue? It sounds like, if this were a good idea, then all of my applications -- LibreOffice, KeepassXC, Remmina, you-name-it should be tasked with adding backends for each cloud provider under the sun. And you'd have to deal with the bugs of each implementation.

Or, developers could simply target the system's filesystem, and the system can manage filesystem backends, including FUSE and/or syncing clients. It serves as an abstraction layer, which prevents needless reinvention of the wheel at the application layer.

[smaudet]

This article explains why it does violate unix philosophy...did you even read it?

Moreover these examples you speak of do all target the cloud versus only targeting the local FS...sure its true that FUSE may serve as a temporary, half-functioning, abstraction, but that does not make it a reason to never use cloud systems....much like none of those programs actually adhere religiously to some unix philosophy that is not actually worth following...

You haven't said anything about my proposal here, just that you like FUSE, which is not a reason to not do something.

[jaap-karssenberg]

Let me weigh in on this.

• If someone wants to spent time and effort to implement a layer to
  integrate with google drive or any other cloud service we should support
  that rather than challenge it
• Zim is open source and requires plugins to be the same, as long as we can
  use the cloud APIs using open source code, I don't see an issue here
• Zim mission statement is to be a desktop application - that stands -
  using files as the medium is important to me, but considering the cloud as
  a remote filesystem is not breaking any hard limits
• Zim being open source is also committed to having open interfaces - e.g.
  for plugins - to extend it beyond what I think it should be :)
• It would be nice to offer local copies of the files as an option so
  integration with other desktop applications works as well -- e.g. the "open
  with" action on an image
• My model would be to make a plugin that does synchronization of a local
  folder with a remote folder and lets the rest of the application to act on
  the local folder
• More general I highly recommend finding a way where the code specific for
  google drive lives in a plugin and only merge patches in zim that open up
  enough framework for it to work - framework should be reusable for other
  remote filesystem plugins -- in that case, the plugin does not need to be
  part of the core set of zim, but can also live in it's own git repository
  for those who choose to use it
• But as stated above, if someone puts time and effort into it, I support
  that, even if my implementation choices would be different.

I do highly recommend working off the "next" branch with Gtk3 / Python3,
else patches need to be ported before integration later on.

On Sun, Apr 15, 2018 at 7:45 PM smaudet [e-mail] wrote:

This article explains why it does violate unix philosophy...

Moreover these examples you speak of do all target the cloud versus
only targeting the local FS...sure its true that FUSE acts as a convenient
abstraction but that does not make it a reason to never use cloud
systems....

You haven't said anything about my proposal here, just that you like
FUSE, which is not a reason to not do something.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jaap-karssenberg/zim-desktop-wiki/issues/415#issuecomment-381424399,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABMMHkWG8RoKvgePO5R1Q8Fl0pIvOlhYks5to4dDgaJpZM4TLvvY
.