|
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #21 Posted on: May 20, 2010, 08:51:14 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Without doubt, versioning will be easier with any sort of directory/archive based "format." Extensibility will also be increased. Now, each approach has some different problems. I've gradated these here:
Storing as a Directory: This is a radical approach that will make copying and sharing tedious. Copying a directory makes the kernel iterate file hierarchy, which there doesn't seem to be a good platform at doing. The alternative is to zip the file yourself, which can be time consuming. The benefit is that the IDE or user can use their own compression scheme, and manipulating resources becomes faster and relatively infallible. Version control would be operable immediately at the push of a button. Selecting the file to load in ENIGMA could be a pain in the ass unless a manifest file is configured: it would just be a directory with an extension; how would ENIGMA know if you just wanted to explore it or if you wanted to explore it?
I would like to propose a solution, part of which I implied in that paragraph. When exploring for a file to open, LGM/the IDE could check for a file called EGMmanifest.egm. If found, it reads it for version, and if the version is sane, it opens it or errors that it is too new/old. Otherwise it just opens the directory. Problem with this is, it would take a lot of work (at least in the APIs with which I am familiar) to specify that behavior when exploring directories. Perhaps Java makes that easier.
That introduces the problem of associating ENIGMA projects with ENIGMA. When you double click a GMK, you get Game Maker. Causing that on Windows/Linux would be a hack at best. For that, I propose that double clicking the .EGM manifest will open the file in ENIGMA. To enable this with mime types, the file could be prefixed with EGM as the first line by standard. Thus, to open their project, users would double click the directory, then double click the manifest. Relatively painless, but somewhat annoying after time, especially with orphaned folder windows.
Storing as a Zip Archive: This has worked for Java for executables for a long time. Not a lot needs written to a Jar at runtime, if anything, but the functionality is out there. This could make writing slow; the question is whether it would be slower than GM's method of packing everything each and every save. Logically, how could it be? But we've yet to see. Association becomes a real prick on Linux, as Linux doesn't care that the extension is a Jar, it sees the ZIP magic number at the beginning of the file. So Linux users would have to Right Click->Open With->LateralGM. Windows users could just double click though, which is who we're really concerned about not offending with trivial tasks.
Sharing would be fast and easy. Versioning would be kind of a pain in the ass, since the entire thing needs compressed, so you have to wait for that, then the versioning application gets to run on it, so you wait for that, then it gets compressed again... Depending on how often that was, I'd be annoyed.
Storing as a PNG-like format: Basically, this avoids the above problems of file association, and takes a different approach to attaining an extensible format. This would be the most difficult for third-party applets to manipulate, as they would, unlike in the other two methods, need an understanding of a special format. It would also introduce problems for versioning amid all the plugins.
Consider that in the other two methods, versioning was ready either all the time or as soon as the file was automatically unpacked by a completely unrelated third-party compression tool (even though zip is embedded into Java's language, it still has nothing to do with ENIGMA). Here, a third party would actually have to do a little research to figure out how to open the file.
Plugins would need a method not only for writing and reading their extension from the file, but for unpacking to a directory for versioning, which is just an example of a functionality that someone may wish to implement that would be lost because individual plugins would have to be designed around it: If the plugin wasn't built to support versioning or numerous other functionalities brought to the table by other plugins, then it simply never will unless the author of the versioning plugin or X new plugin specifically codes a method for all the extensions. In case the sheer amount of information in that paragraph made my meaning unclear, I am saying that coordination between formats that are entirely plugin-dependent can be difficult for a new, unrelated plugin.
Also, the "reading" part of this format is likely to get messy due to Ism having no way of knowing (as far as I can tell) how they (plugin/extension programmers, though they don't exist) label their extensions to the format. Not to mention that the order of plugin loading is likely to change from instance to instance of installed versions, so Ism can't just iterate the plugins asking if this is their work: they could be called prematurely. Basically, Ism would have to make calls to each plugin who has registered itself as a format editor to ask, "Is this your doing? If so, undo it." These methods would all be called (until one fessed up to it) on every extension.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
luiscubal
|
|
Reply #22 Posted on: May 20, 2010, 09:11:15 am |
|
|
Joined: Jun 2009
Posts: 452
|
As for ZIP Linux file association, there is a nasty side trick you can try. Most Java APIs rely on Input/Output Streams. To block Linux file detection, you could prefix every single file with "Eni". Only three bytes, won't have any visible effects on the saving/loading speed(compare 3 bytes with the total file size). It should be, however, to completely break linux file association, as intended. The side effect is that you would no longer be able to extract the archives using traditional tools but, then again, no programs should accidentally treat Eni files as zips.
A simple reading code snippet for Java coders:
FileInputStream fis = new FileInputStream(argv[0]); fis.get(); fis.get(); fis.get(); //Error reporting here would probably be useful ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
|
|
|
Logged
|
|
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #26 Posted on: May 20, 2010, 02:23:55 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Well, my Jars open with the archive manager.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Josh @ Dreamland
|
|
Reply #28 Posted on: May 20, 2010, 07:43:45 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
Nope. Bitches not marked executable if not so, otherwise opens in archive manager anyway. Even though I just picked Sun Java 6 Runtime.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|