[I7] I7 projects and bundle files

[Andrew Hunter]

On 31 Dec 2007, at 00:19, Jesse McGrew wrote:

> On Dec 30, 2007 2:42 PM, Andrew Plotkin <erkyrath at eblong.com> wrote:
>> On Sat, 29 Dec 2007, Jesse McGrew wrote:
>>
>>> For this reason, I must disagree with Andrew that zipped projects  
>>> are
>>> only for people who know how zip works.
>>
>> Then disagree with *both* claims, because it cuts both ways.
>>
>> Any flat assertion of "we know how the user wants to manage his  
>> source
>> code" is going to be wrong for a lot of users, and will be a nasty  
>> kick in
>> the shins to some (current) users. Can we please not unilateratally  
>> and
>> mandatorily change the project format on everybody just because it  
>> would
>> be convenient for XO?
>
> Mandatorily, no. But I do think making a single-file project the
> default is best.
>
> Inform 7 projects currently stick out like a sore thumb among all
> other document types. What other program saves its projects as a whole
> folder, except for Mac-only programs where you can't tell the
> difference without looking closely anyway?

Actually, that's easy to answer: pretty much any IDE works like this  
due to the necessity of having multiple source files. This is really  
where Inform's file structure design came from, especially as it  
supported multiple source file projects up to a few weeks before  
release (in fact, it still does support them: the UI is merely hidden).

> It seems to me that the current project format is an artifact of I7's
> origins on the Mac, and no offense to anyone, but it gives the
> impression that portability was not a major concern in the IDE's
> development. On other platforms -- speaking mainly of Windows, but I
> believe it's true on Linux too -- you can't double click on a project
> and have it open in I7. You can't attach a project to an email. You
> can't upload a project all at once using a naive FTP client. The world
> outside of Cupertino is just not set up to treat folders as documents,
> and using folders as documents doesn't seem appropriate for a
> release-quality app.

Most of these criticisms would also apply to a Visual Studio project  
or an Eclipse project: certainly these were the lines I was thinking  
along when I designed the format: the ability to treat a project as a  
unit seemed like it might be convenient, so they were made to be  
packages - that was really just a bonus, it would still have been  
multiple files even if that were not possible. (The equivalent of  
the .sln file would be the .plist file, which perhaps could have been  
given a better extension).

> The current project format has only a few benefits:
>
> * It's the way it's been done so far.
> -- But if there's a good reason to break that tradition, and I believe
> there is, then the time to break it is sooner, not later.
>
> * It's easier for Inform and the IDE to read files in a directory than
> to parse zips.
> -- But not that much easier. The IDEs have access to zip libraries,
> and they can pull the files out into temporary space where NI, Inform
> 6, and cBlorb can work with them.
>
> * It gives experts easy access to files like story.ni and auto.inf.
> -- But you can cut 'n paste story.ni from the IDE. Auto.inf and
> auto.z5 will have to be written to a temporary location anyway: they
> don't logically belong in the zip, and Inform 6 can't read or write
> zips. The other files are probably only useful to utilities that can
> be updated to parse zips.
>
> Am I missing anything? If we were starting over from scratch, would
> there be any good reason to choose a folder-based project format
> instead of a single file?

A folder based solution allows the contents to be presented as text  
files that can be easily interpreted by other utilities. Source  
control springs immediately to mind: I imagine that it's not the only  
reason to want to see the contents of the project in a simple form; by  
using such a format we're really limiting manipulation of the contents  
to the IDE and the compiler - certainly you would need to be  
determined to write a third-party tool to alter or manage a project's  
source code.

The additional complexity required to do this concerns me as well. The  
compiler does not produce a single output: it produces a fairly large  
collection of output files that are processed by the IDE. At the  
moment these are written into the project directory which means that  
the IDE just needs to tell the compiler where the project lives, let  
it update it as it will and then update itself when it's done. This  
isn't possible with a single file solution: because the user can still  
perform edits while the compiler is operating it would be a recipe for  
disaster.

So instead the IDE would have the responsibility of setting up a  
workspace for the compiler to run in, putting the necessary files  
there, updating them, refreshing itself and the archive file and then  
cleaning everything up after a compiler has finished. It would also  
need to deal with the corner cases: cleaning up after a crash  
(compiler, IDE, or both together), dealing with the user quitting in  
the middle of a compile, and I think the case where the user edits the  
source text during a compilation becomes more complex as well. It's  
inevitably going to be more fragile.

The final thing is that a corrupt zip file is typically pretty  
unreadable, so the cost of failure is a completely lost project. A  
save operation would have to be atomic, and I think would also have to  
be from a known-good data set (that is, one that is verified to  
unarchive and reproduce the correct source text).

I think that something that has also been missing from the discussion  
is the nature of the 'materials' folder: as long at it exists this  
discussion is moot anyhow as it is just as much part of the definition  
of a project as the source code.

Andrew.