rejetto forum

Software => &RQ => Topic started by: alkimiya on May 11, 2004, 06:21:51 PM

Title: &RQ.NET Planning Thread
Post by: alkimiya on May 11, 2004, 06:21:51 PM
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 (http://www.stud.uni-karlsruhe.de/~uck4/ICQ/)
OSCAR Protocol (http://iserverd.khstu.ru/oscar/)

(c#/.net related)
Visual C# Developer Center (http://msdn.microsoft.com/vcsharp/)
.NET Framework Home (http://msdn.microsoft.com/netframework/)
Mono (http://www.go-mono.org/)
SharpDevelop (http://www.icsharpcode.com/OpenSource/SD/Default.aspx)
Title: &RQ.NET Planning Thread
Post by: rejetto on May 12, 2004, 01:21:37 PM
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
Title: &RQ.NET Planning Thread
Post by: Anonymous on May 13, 2004, 06:39:06 PM
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.
Title: &RQ.NET Planning Thread
Post by: alkimiya on May 13, 2004, 07:09:30 PM
Quote from: "Suicide"
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.

Quote
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  :P
Title: &RQ.NET Planning Thread
Post by: Anonymous on May 13, 2004, 08:16:03 PM
Quote from: "alkimiya"
I can.. but I won't  :P
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
Title: &RQ.NET Planning Thread
Post by: rejetto on May 14, 2004, 02:22:50 PM
i can't spend time on the exporter, but you can find a file "&RQ history file format.txt in sources archive.
Title: Program updates
Post by: alkimiya on May 27, 2004, 05:22:11 PM
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.
Title: &RQ.NET Planning Thread
Post by: rejetto on May 28, 2004, 10:18:34 PM
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.
Title: &RQ.NET Planning Thread
Post by: alkimiya on May 29, 2004, 10:25:53 AM
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.

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.
Title: &RQ.NET Planning Thread
Post by: Optex on June 09, 2004, 04:42:26 PM
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
Title: &RQ.NET Planning Thread
Post by: alkimiya on June 09, 2004, 10:28:39 PM
Quote from: "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.

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

Quote
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.

Quote
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.

Quote
&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.
Title: &RQ.NET Planning Thread
Post by: rejetto on June 10, 2004, 05:44:02 PM
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.
Title: &RQ.NET Planning Thread
Post by: Optex on June 11, 2004, 07:53:22 PM
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
Title: &RQ.NET Planning Thread
Post by: drunk+monkie on June 12, 2004, 12:56:26 PM
so how is it going so far?
any luck? :)
Title: &RQ.NET Planning Thread
Post by: rejetto on June 12, 2004, 07:30:46 PM
Quote
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.
Title: &RQ.NET Planning Thread
Post by: drunk+monkie on June 14, 2004, 07:24:01 PM
words of wisdom, rejetto!
Title: &RQ.NET Planning Thread
Post by: Riz on July 02, 2004, 12:28:46 PM
Why don't you use Delphi 8 For the Microsoft .NET Framework?
Title: &RQ.NET Planning Thread
Post by: alkimiya on July 02, 2004, 01:03:58 PM
Personally, I think Borland's IDEs suck.. but they're free for personal use so probably the tool will be Borland C# Builder, since this can import/export Visual Studio .NET projects I can stand this if I'm on the developing team.

Since the program will be rewritten from scratch, there's no real benefit from using Delphi.NET over C#.
Title: &RQ.NET Planning Thread
Post by: rejetto on July 04, 2004, 08:00:35 AM
delphi 8 is not free
Title: &RQ.NET Planning Thread
Post by: Sergius_ on July 19, 2004, 05:32:17 PM
.NET is a revolution. It has so many advantages so i simply don't understand people, who tell that their choise is not to use .NET at all. C# is the second native language for .NET (after MSIL), it is elegant, well thought-out and as for me the best language. Someone told that .NET programs run slowlier than native... the difference is that .NET code is managed and it means that definite part of source code will be compiled runtime to native ONCE and after it compiled code will be used. So it is slowlier just the first time it is executed. Java is muuuuuch slowlier than .NET, i don't want to pay attention on it at all.
So, don't fuck Rejetto's mind with native, java, c++ and all other shit.
.NET (and Mono) and C# + #Develop is right way.

Greetings from Belarus. (íàðîä, îòñòàíüòå îò rejetto ñî ñâîèìè íåêîíñòðóêòèâíûìè ïðåäëîæåíèÿìè. Åñëè áóäåò &RQ.NET áóäåò êðóòî. À òàê - ïðîñòî óáèâàåòå æåëàíèå ÷òî-òî äåëàòü ó ÷åëîâåêà).
Title: &RQ.NET Planning Thread
Post by: drunk+monkie on July 22, 2004, 06:43:24 PM
:) hey man we don't say sh*t anymore. We just want our godfather Rejetto to do something with this project, not lettin it die and get old (in some moral aspects). I mean no matter how good it is, if there's no development, there's no movement. i.e. it's dead. and it's rottin, you know...

Rejetto, we believe in!  :roll:
well, at least I do :)
Title: &RQ.NET Planning Thread
Post by: fan on August 05, 2004, 10:09:15 PM
Quote from: "drunk+monkie"
:) hey man we don't say sh*t anymore. We just want our godfather Rejetto to do something with this project, not lettin it die and get old (in some moral aspects). I mean no matter how good it is, if there's no development, there's no movement. i.e. it's dead. and it's rottin, you know...

Rejetto, we believe in!  :roll:
well, at least I do :)

Support ! awaiting new releases


&RQ fan
Title: &RQ.NET Planning Thread
Post by: MioGreen on August 10, 2004, 09:36:55 AM
I think so... C# is the best language... It s simple and powerfull... &RQ.NET - must be :) If you know C# fun club, please mail me :)  miogreen@mail.ru
Title: &RQ.NET Planning Thread
Post by: Sergius_ on October 07, 2004, 07:43:39 PM
WHERE IS IT???? I NEED IT!!!!
Title: &RQ.NET Planning Thread
Post by: alkimiya on October 08, 2004, 03:14:12 PM
Quote from: "Sergius_"
WHERE IS IT???? I NEED IT!!!!

Lay off the sugar ;)

Warning.. technical stuff ahead... stop reading if you don't understand anything about anything :P

I'm pleased to announce that I've written a quite cool application framework (codename ApplicationFramework :) ) in C#2.0, where I'm currently a module implementing ICQ protocol. Whether this will be useful for &RQ.NET or not is dependent on

1. A non proprietary IDE with support for .net framework 2.0 will be available
and
2. Rejetto approves of the design.

Anyway.. the module handling system will support loading/unloading modules at runtime (which means program can be auto-updating, without restarts, the exe will never change, only the module dlls). Also is support for automatic serialization/deserialization of module settings at load/unload. It will be up to every module to implement a user interface, protocol or any other stuff. Modules communicate through commands, queries and events (that can be registered/unregistered at will).

Planned are features for automating internationalization of modules, but since this is a hobby project, things may or may not be done.

This also makes deployment easier, all you have to need is to download the exe, and the exe can then let you choose a set of default modules to download and install from &RQ server). That means no zip-file, and the exe will hopefully never change (just the module dlls).
Title: &RQ.NET Planning Thread
Post by: Electron on October 08, 2004, 04:20:24 PM
Well, sounds too good to be true :) But, I'll hope.
And when should we be able to download first examples of your work? :)
Title: &RQ.NET Planning Thread
Post by: alkimiya on October 08, 2004, 04:30:18 PM
Quote from: "Electron"
Well, sounds too good to be true :) But, I'll hope.
And when should we be able to download first examples of your work? :)

Well.. ICQ protocol is about 30% implemented and non-tested at best.
I will implement everything documented at http://iserverd.khstu.ru/oscar/ plus direct connections for file transfer eventually.
A protocol in itself is not very useful without some gui:s as well.
Expect many months until something even resembling &RQ as of today.
Title: &RQ.NET Planning Thread
Post by: rejetto on October 09, 2004, 06:58:15 AM
lately i found frustrating trying to work with C#Builder
i made something wrong and i can't get the GUI designer anymore 8O
i got stuck for months just because both .NET and Python lack a decent Tree control, as i have on delphi6.
.NET 2 has such control, i think i will explore Microsoft IDE. the beta is free.
Title: &RQ.NET Planning Thread
Post by: USER728472384 on August 22, 2005, 11:20:12 AM
.NET is shit, why to port &RQ to .NET? Port it to JAVA (and to mobiles)  instead!
Title: &RQ.NET Planning Thread
Post by: BruteHost on September 06, 2005, 02:32:34 PM
Quote from: "USER728472384"
.NET is shit, why to port &RQ to .NET? Port it to JAVA (and to mobiles)  instead!
sorry, often working with java apps...
20-40 mb op.memory in avr. is usual thing for them :(
Title: &RQ.NET Planning Thread
Post by: joxy_ on September 20, 2005, 07:45:21 AM
Quote
joxy: Compile new sources runtimely can easily be added to Java, just noone implemented this.

In fact, every IDE has a debugger which compiles changed sources into the running executable, all in runtime.

MSVC supports this, too. (This is called "Program Edit and Continue").
Title: Re: &RQ.NET Planning Thread
Post by: Damme__ on October 18, 2006, 07:29:19 AM
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

Please Please Please, Use simple C / C++, or Delphi, do not use c# , the program cant be optimized at all if coded in c#, it will be heave, large, slow, laggy.. Noone will run a program like that, not even microsoft themselves uses C#!!!