Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PTTG??]

...
1) In order to upload a file to an existing world, the user must have a lock on that world
2) In order to get a lock on that world, the user must be logged in and the world must be not locked

No restrictions on downloading.  Anyone wishing to fork (or just play the world with no intention of uploading at all), can download at any time.

So it doesn't matter if it takes them 20 tries to download the file, the lock and the download are logically separate...

Then what is the lock for?

[keith.lamothe]

Then what is the lock for?

In the always-allow-downloads case, the lock is to preserve the existing straight-line descent of that world under the name of that world.  Any created-by-fork world would have to have a different name, so if you wanted to follow a particular world you could do so by remembering the name.

Without the lock "Player A" would have no way of knowing that "my upload will go under World X", because "Player B" could upload a new version to World X in the meantime and Player A would have to create World X-2 or something.  Essentially every upload would be a fork, with no child node having priority over its siblings in the tree.

We could also allow a world to be designated "do not allow forks" or "if locked, do not allow downloads by anyone but the user holding the lock".  The latter would be somewhat looser than "only allow lock by user in private group, and do not allow downloads by anyone but the user holding the lock".

[PTTG??]

I'll say it again, I just don't feel that there will be much advantage to such a lock-based system. I'm afraid you'll get people locking worlds and then forgetting about them or otherwise trolling.

The worst that can happen without locks is... someone puts up a confusingly-named fork of a popular world.

I'm saying that long world threads will happen automatically; people will wait and take worlds pretty well, and if they don't want to, they can just take an old version.

If anyone abuses the freedom, others will not play with them, and there you go. Self-regulating.

[Puzzlemaker]

Hmm, you might have a point, but I don't know.  Put up a test subversion server that we can play around with?

[keith.lamothe]

I'll say it again, I just don't feel that there will be much advantage to such a lock-based system.

You may be right.  It would be worth trying it without the locks first to see if they're really necessary.

In that case, is there any major problem with, instead of subversion:

1) FTP Server
2) Public read rights
3) Anyone with a username/password has upload rights (need to restrict file type in some way, probably, or people will start dumping .mp3s and stuff)
3) Only mods have delete rights (so the old world uploads are still available)
4) Encourage people to use a meaningful naming convention (i.e. InfiniteRealms_Boatmurdered_Y410_M3)
5) Have people post descriptive information and file links in the forum?

I ask because setting up and running FTP is considerably simpler than SVN, it just has no "check-out-check-in" mechanism or any real capacity for metadata on the files.

[Footkerchief]

SVN will avoid a lot of the redundancy across save versions.  Judging from my save folders, this could reduce the needed storage space by maybe 50% (the other 50% is in world.sav).  It will also eliminate the need for players to manually handle versioning, which is invaluable.

It'll also be easier to write a nice little custom-suited client for it.

[PTTG??]

I'll say it again, I just don't feel that there will be much advantage to such a lock-based system.

You may be right.  It would be worth trying it without the locks first to see if they're really necessary.

In that case, is there any major problem with, instead of subversion:

1) FTP Server
2) Public read rights
3) Anyone with a username/password has upload rights (need to restrict file type in some way, probably, or people will start dumping .mp3s and stuff)
3) Only mods have delete rights (so the old world uploads are still available)
4) Encourage people to use a meaningful naming convention (i.e. InfiniteRealms_Boatmurdered_Y410_M3)
5) Have people post descriptive information and file links in the forum?

I ask because setting up and running FTP is considerably simpler than SVN, it just has no "check-out-check-in" mechanism or any real capacity for metadata on the files.

Now this is something I can get behind. The only thing I'd add is that I thought this might include a separate downloader program, something to decompress and install any related files, possibly including mods- or even graphics packs. In other words, you could open up the browser folder, sort them by age, for instance, and select the top one. Looking at this, you can see all the previous games in this world, each comment, and if it includes any metadata. After this, it's a one-click process to download the files, which the DLer will decompress and put away in DF.

[keith.lamothe]

In other words, you could open up the browser folder, sort them by age, for instance, and select the top one. Looking at this, you can see all the previous games in this world, each comment, and if it includes any metadata.

How, exactly, would metadata such as
1) age of the world
2) name of the world (not necessarily the in-game name, just a consistent one)
3) uploader comment

Be associated with game files uploaded to an FTP server?

A few ways come to mind, but they're nasty and/or inconsistent, what way are you thinking of?

Thanks,
Keith

[PTTG??]

Well, working with video, one could just create an nice .xml with the same name and have the browser grab both; or you could snap something into the .zip (assuming we compress the save file), only problem with that being you'd have to download the whole thing to get it.

Or we could have a file structure like this:
[a file] {a folder}

{archive}:
[index.xml]{world1}{world2}{world3}...

{world1}:
[save 1.zip][save 1 metadata.xml]{save 1 descendants}

{save 1 descendants}:
[save 2a.zip][save 2a metadata.xml]{save 2a descendants}
[save 2b.zip][save 2b metadata.xml]{save 2b descendants}

To display the history of any save, show that metadata, followed by the metadata of the previous branch up, and so on.


Of course, I'm pretty sure there's a big flaw with that that I'm not seeing. Probably a system like this already exists, and SVN may be what I'm thinking of. I'm just not sure that svn will allow easy browsing and selection. What I'm familiar with is just an automatic updater without much of a UI at all.

[keith.lamothe]

Of course, I'm pretty sure there's a big flaw with that that I'm not seeing.

That's a pretty decent structure, actually.  The difficulty is ensuring the integrity (or even presence) of the xml metadata and the folder structure.  Normal FTP clients would let people do whatever they wanted; we could set up sweeping rules like "non-moderators can't delete or modify existing files", but any world- or save-specific rules would probably be unsupportable.  The other difficulty is how to make and update the xml files since users are unlikely to hand-code them.

However, if the only access to the ftp repository were through special client software then those rules could be consistently enforced.  That would be essentially workable.

The issue I would have with that approach is that writing the special client software would equal or exceed the complexity of the web application idea I proposed earlier.  One option is a desktop-based client software requiring a version for every platform that supports DF (windows, linux, mac, others?), as well as at least some small server-side software which prevents the client software from doing things it shouldn't (if someone hacks their client).  This is essentially re-inventing the client-server model of SVN or CVS.  The other option is a web-based client which is essentially a web application, the only difference being that the metadata is stored as xml in the file system rather than in a SQL database (and FTP would be irrelevant at that point, just have the custom server software manage the files).

Or am I missing something in your suggestion?

Thanks,
Keith

[PTTG??]

...Or am I missing something in your suggestion?

No, you've got it.

I may be able to get Tahin to build some of this. He knows how to make internet communication software and I'm sure he can easily assemble a sudoSVN.

The main thing I like about a desktop rather than web app is that we could do a lot of the installation and exportation automatically; a surprisingly large group of DF users aren't interested in messing with any of the basic files.

[Servant Corps]

How Tahin's doing?

[jaked122]

I'm no programmin' type, but I can imagine there would be a way to, once one person has chosen "World A", to remove "World A" from the list of accessible worlds until it's returned. my Uni library's version of E-Book checkout is like this

(Which makes no sense to me. I get why only university computers can access the E-books the uni has bought, but if it's a PDF, why is only one person allowed to read it at a time?)

if you can get linux, install okular, go to the preferences and disable "respect DRM".

[Servant Corps]

*bump*

Anyone here actually doing anything with this idea?

[Huin]

SVN will avoid a lot of the redundancy across save versions.  Judging from my save folders, this could reduce the needed storage space by maybe 50% (the other 50% is in world.sav).  It will also eliminate the need for players to manually handle versioning, which is invaluable.

It'll also be easier to write a nice little custom-suited client for it.

I'd suggest that experimentation would be required for seeing if SVN would really cut down the storage space redundancy. It pretty much comes down to the total size of the files that change between "revisions" of a world. Some experimentation would be required to see the size of the files that do change between revisions - the trouble is that the files appear to be completely binary, and SVN can't do diffs between binary files.

You *might* have some luck with a custom system that either uses something generic ( http://www.daemonology.net/bsdiff/ ) or a custom program that examines world files and can produce a compact data file describing the difference - although that would be a significant investment of time, and would be subject to break whenever the save file format changes.