Andruha on 28/4/2005 at 19:38

---

I started this thread not to underrate anybody and I respect work of other people. "some programming" was in my reaction to ZylonBane. Moreover, it was refering to my own implementation idea, which, as I stated myself, took a couple of minutes to come up with and it "sucked" ;). By no means was it a general statement. One can choose to look for my similar phrases and most probably will suceed as there's plenty of text to brush in this thread and I am not a robot to check all words I type (words of a foreign language, by the way). Or one can choose to skip the noise and focus on the message itself.

To answer the rest of your post, I will:
- skip RSS, multiplatform development, C++, sharing of code, modularity, as these things are either features that can be added or are implementation oriented, which is not what conceptual design is about.
- clarify unification, standards and interoperability in the context of a mod loader:

Unification
It was meant as opposite to going with different loaders for different target applications or versions of the same mods. Now, let's forget about this word.

Interoperability
There are two primary entities - a loader application and a mod, so interoperability boils down to how to make sure that any loader works 100% with any mod (regardless if the latter is in rar or zip, or 7zip format; or the latter's briefing is HTML or RFT). Interoperability is achieved via customization system (e.g. plugins) and relies on standards.

Standards
Apply mostly to mods (more presisely the metadata about mods).
Loaders come and go. A mod stays. It is all about a mod. Therefore standards should be chosen with a mod in mind (not with one of possibly many loaders).

Finally, a Loader is a closed system and nobody should care about how it works as long it performs its function. Therefore, there is nothing in the proposed design that dictates developers how to implement a loader; its (design) purpose is to help them focus on essentials and to make them aware about areas that might affect interoperability and standards. Things like compression formats, C# or C++, RTF or HTML, are not important, just details.



Here are some suggestions:

In the diagram, I intentionally separated the syncronization tool (further on, SyncT) from the profile (syncronization description). Here is why:
- it makes function of SyncT simple and clear: copy/delete/verify files; it works with source and target file; it should read source->target description from external file.
- keep profiles human readable (so that knowledge about T3 installation idiocincrasies will be available to others; also makes profile debugging easy)
- syncronization description should not be in the form of instructions for your SyncT (e.g.: cp X Y), just a description of a task (e.g., src: X; tgt: Y; fun: copy)
- think about hierarchical profile (optional)
The above makes you independent from the actual profile; it allows you work on SyncT and mod community on profile in parallel. It also will make very easy to extend FleshLoader to support T1, T2, TDM - they will be just different profiles, no coding will be required. Readability is a big bonus too.

Another suggestion: please consider making SyncT work (copy, delete, etc..) with file objects rather them deligating those operations to OS. Here's why:
1) it will allow adding plugins in the future. A pluggin can add support e.g. for remote files, compressed files, etc.. without changing the Loader.
2) file object interface is well documented, quete universal and easy to work with.

Dracflamloc, I really value your presence in this thread as you are working on the new loader application. I hope that the heated discussion has left you open to suggestions from me.

dracflamloc on 28/4/2005 at 21:24

---

Okay.
I'm open.

But I don't see my part of these conversations as "heated".

Maybe Zylon's...but what else is new eh? :)

Glad you clarified some stuff. I didn't read too much into this thread apart from your posts. And I typically don't read anything posted by Zylon unless it direct addresses me, so if I mistook anything you said it was all from your first post really.

I'll read over your design when implementing FleshLoader components and try and keep it as open as possible. For the format I've decided upon using a .zip file. It's crossplatform, standard, and pretty much any archiver a developer chooses to use will be able to extract it.



@Zylon
Nothing personal man. I just don't have time for your typical posts. I'm sure you say things in a respectable manner sometimes.