&RQ.NET Planning Thread

[alkimiya]

I thought it could be useful to coordinate development in this forum, for instance we could have a list of features to be implemented and by whom. It will be a while before any working version is available, nevertheless feel free to add your wishes in this thread.

This first post will consist of status of current plans and will be edited by me when due.

First.. I would like to know, what parts should &RQ consist of. I can think of a few myself.. but they're open for debate. It's good to divide code into different assemblies, for instance one dll for icq protocol, another maybe for themes management and so on..

List of assemblies:
1. Core functionality, helper functions, plugin management etc.
2. Instant messaging protocols (one per protocol preferable)
2a. ICQ
2b. MSN
2c. AIM
2d. IRC
2e. ...
3. Graphical interface
3a. Contact List
3b. Chat Window
3c. Preferences Window
3d. ...
4. Import/Export (import from old &RQ, Miranda, ICQ, export to text)
5. History management, statistics etc.
6. ...

Tasks:
1. Planning (active)
2. ...

Links to good resources:
(icq related)
ICQv8 Protocol
OSCAR Protocol

(c#/.net related)
Visual C# Developer Center
.NET Framework Home
Mono
SharpDevelop

[rejetto]

i want to say few things
- C# is likely to be the technology we will use for the new &RQ for several reasons
- i'm already designing classes
- i'm studying C#
- i'm using #develop, and it should be the preferred tool since it is free
- i'm a C# newby, and this is not a good thing. must be aware (and experienced) of tools the language offers you, to choose the right tools (ad i'm not talking about software tools...not only). i'm afraid i won't choose the right tools.
- it will be multi-protocol, and it will support non-IM protocols, like IRC
- the core development should involve ~2 developers
- shame on who asks about ETAs

[Anonymous]

1) only lamers need lame irc build-in clients like dll shit in miranda (dont waste your time)
2) who needs another non icq shit ? i mean msn/yahoo (i can understand aim support as maximum)

ps: its wrong place to ask, i understand, but ru ppl (and me) wondered if someone can write an app to convert history from &RQ to miranda.

[alkimiya]

1) only lamers need lame irc build-in clients like dll shit in miranda (dont waste your time)
2) who needs another non icq shit ? i mean msn/yahoo (i can understand aim support as maximum)

I asure you, ICQ support will precede other protocols, then it will be fully configurable.

ps: its wrong place to ask, i understand, but ru ppl (and me) wondered if someone can write an app to convert history from &RQ to miranda.

I can.. but I won't  

[Anonymous]

I can.. but I won't  

you re so cute  :?  :crazy:  :|
as for me, &RQ becomes very buggy (when you speak not only english), i think it will gain more troubles in future, so as every normal persone i want to move to more perspective and constant developing miranda or something (with no bullshit like this thread of "to do deee doooo list").
but i also dont wont to lose my history (belive me if i ll want to move to miranda i ll do it anyway, history wont stop me, i think u understand)

also its not the best way of preventing users moving to miranda answering NO on my request

[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]

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.

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

[alkimiya]

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.

.net is way faster than java for gui applications, and .net IS crossplatform

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

Yes, it is, but it's harder to program. .net (like java) has many powerful (if not that fast) constructs that will make programs less buggy and easier to debug.

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

The update facility is not something that makes the program slower, it's a bonus from good design. Since we don't want to make one monolith program (multi-protocol, protocols optional) having a modular design enables runtime updates.

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

Indeed it is. But Delphi is somewhat limited (imho) and since the code is kind of messy, a total rewrite is needed.

[rejetto]

Delphi and Java is much more limited than C# or Python, just because they can't compile new sources run-time.
this is a very powerful feature and it is fundamental in my choice.

[Optex]

Some ideas of .net and java projects are good, but I think that it`s not time for them - not so fast hardware
Easier way`s not always right.

Delphi, python, c#, java...
where ic c++?
C++ with Qt is good, powerful instrument
or with winapi, but i dislike it, because now i using linux

.net is your choice. respect, rejetto.
I`ll never use &RQ.NET. It`s my choice.
maybe, I`ll never use .net at all

Good luck in your work

to alkimiya:
I don`t say that .net isn`t crossplatform
i know, update facility is not something that makes the program slower.
All what I want to say, that native code is faster
about design: what about plugins?

I`ll be wise and will respect your tastes and choices.
All ideas, projects etc have right to live

I afraid, that time, when programers will have very mutty ideas about programing are coming

[drunk+monkie]

so how is it going so far?
any luck?

[rejetto]

it`s not time for them - not so fast hardware

did you see client software made in C#/Python ?
i did, and it was fast.
and it is not weird in a world made of GHz.
here in italy you can buy 2GHz CPU for 50€.
this software will be stable maybe the next year, there's no real interest in supporting CPUs with less than 1GHz.
C++ is good for speed, nothing else.
To compare 2 languages/tools, you have to experience both.