Software > &RQ

&RQ.NET Planning Thread

<< < (2/7) > >>

rejetto:
i can't spend time on the exporter, but you can find a file "&RQ history file format.txt in sources archive.

alkimiya:
I think &RQ should be (optionally) auto-updating in runtime. The .NET framework certainly makes this possible. Say for instance, the GUI module has updates but ICQ module has not. The core can unload the GUI, download the new version of GUI.dll (or whatever name it has) and reload the module without other parts must shut down, for instance connection to ICQ server doesn't go down while updating (no program restart). This is also very good for testing during development.

A few considerations:
1. To be able to unload dll:s (and replace them) they must be loaded in separate AppDomains, and types particular to the dll cannot be used outside the dll (or that dll will be locked by the domain that uses it). It is crucial that dll:s can be unlocked.
2. Compatibility, a change in one module might be dependent on changes in other modules. Should this dependency be dealt with at compile time or in runtime (modules not in any way dependant on each other, only at program core).
3. Deployment.
This model makes changing the &RQ program exe a very rare event. It is however important to notice that the program will be split in several (maybe many) smaller files.

rejetto:
i don't understand your interest in updating without restarting the software.
people don't update twice at day, and programmers can start another instance for testing purposes.
if this feature requires the core source to be much more complex, it should be discarded.

alkimiya:

--- Quote from: "rejetto" ---i don't understand your interest in updating without restarting the software.
people don't update twice at day, and programmers can start another instance for testing purposes.
if this feature requires the core source to be much more complex, it should be discarded.
--- End quote ---

Well it has benefits in distributing also.. you can let people download a 10k exe once and let the exe download whatever extra is needed.

I don't think the code will be more complex, on the contrary, you will isolate errors to a specific module and code will be clearer, since this is a core design "template". Let each module have a central entry point (for commands/queries/events). I think it's better to address these issues at the start than when the code already is complex.

What do you think of modular design? What functionality do you see in the core?

If people update (to the latest non-beta versions) automatically, there can only come bug reports from one version. Let the modules lie on sourceforge or something, with a xml file that the program can parse with direct urls to all module versions.

Optex:
Why MS.NET ???
It`s your choice, but I think,  Java is better than than this MS`s creatutre.
Java is more crossplatform language. And open source will understand you better. And it have all positive features of .NET and have less negative. IMHO, of course.

In general, I prefer native code. It is faster then Java byte-code and  .NET code.

I can restart program after update. It is better than to use slow and heavy software.

&RQ written on Delphi was the best ICQ-client. Why not to make it better than it was?

PS. .NET way is like nil-pointer

PPS. Sorry for my english - it`s not my strong side

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version