[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: [GSOC] Project Idea : KDCPP( KDE Kross DC Plus Plus)
From: gaurav gupta <1989.gaurav () googlemail ! com>
Date: 2010-03-28 18:54:54
Message-ID: f4e1c521003281154n7d14c7f9s1dea66b1c81b174b () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello Folks,
This is Gaurav, B.Tech. Final Year Computer Science & Engineering from
Institute Of Technology - Banaras Hindu University, India. Me and My friend
J.R.Harshath Was working on a DC++ client(XDC) and then got busy in regular
curriculum. I just got a though that why not to add this in KDE so just
posting some details about kdcpp. Please have a look and let us know that
would you like this to be a part of KDE.
1. DCPP Client Will be in two parts
1. Core runs as a background daemon(Provides all functionalities)
2. Front end GUI - connects to Core over TCP / IP and lets the user
manage the system, thereby enabling a user to manage his DC++ from any
machine reachable over network.
2. Core Will have three Main parts
1. UIConnectionListener (Which will listen messages from kdcpp GUI )
then UIAction( Action corresponding to particular message)
2. HubConnectionListener (Which will listen messages from dcpp ) then
HubAction( Action Corresponding to message like download file,
filelist etc
)
3. CoreAction (Deals with various tasks to be done by core like file
hashing)
3. Communication Protocol (First We were working on Client DC
communication)
1. We decided very simple New Line Separated Protocol (Which can be
further extended to some xml based protocol, just change the
implementation
of uimessage class).
2. Protocol details are like
1. Commands from the client to daemon ($command)
2. Responses to Commands ($response)
3. Notifications from the daemon to the client ($notify)
Format of $command:
$command
<messageId>
<clientId>
<Command>
<arg1>
<arg2>
...
$end
The args will, of course, depend upon what the Command is.
4. We are not developing client and testing our functionalities using
telnet.
5. Once core daemon and client interaction part is done we are planned to
start working on HubConnectionlistener and Core Action Part.
6. We have already developed and designed some part of it which can be
viewed at http://github.com/jrharshath/xdc.
So looking for the comments on the project and if KDE developers are
interested then I would request interested developers to mentor us in
GSOC10. Then we will decide our solid boundaries for this GSOC10 and can
take this further.
Thanks & Regards,
GAURAV GUPTA
B.Tech IV Yr. , Department of Computer Science & Engineering
IT BHU , Varanasi
Contacts
Phone No: +919236964262
e-mail : gaurav.gupta.cse06@itbhu.ac.in
1989.gaurav@gmail.com
[Attachment #5 (text/html)]
Hello Folks,<br><br>This is Gaurav, B.Tech. Final Year Computer Science & \
Engineering from Institute Of Technology - Banaras Hindu University, India. Me and My \
friend J.R.Harshath Was working on a DC++ client(XDC) and then got busy in regular \
curriculum. I just got a though that why not to add this in KDE so just posting some \
details about kdcpp. Please have a look and let us know that would you like this to \
be a part of KDE.<br>
<ol><li>DCPP Client Will be in two parts</li><ol><li>Core runs as a background \
daemon(Provides all functionalities)</li><li> Front end GUI - connects to Core over \
TCP / IP and lets the user manage the system, thereby enabling a user to manage his \
DC++ from any <br> machine reachable over network.
</li></ol><li>Core Will have three Main parts</li><ol><li>UIConnectionListener (Which \
will listen messages from kdcpp GUI ) then UIAction( Action corresponding to \
particular message)<br></li><li>HubConnectionListener (Which will listen messages \
from dcpp ) then HubAction( Action Corresponding to message like download file, \
filelist etc )<br>
</li><li>CoreAction (Deals with various tasks to be done by core like file \
hashing)<br></li></ol><li> Communication Protocol (First We were working on Client DC \
communication)<br></li><ol><li>We decided very simple New Line Separated Protocol \
(Which can be further extended to some xml based protocol, just change the \
implementation of uimessage class).</li>
<li>Protocol details are like<p> 1. Commands from the client to daemon ($command) \
<br> 2. Responses to Commands ($response) <br> 3. Notifications from the daemon \
to the client ($notify) <br> </p><p> Format of $command: <br>
</p> $command <br> <messageId><br> <clientId><br> \
<Command> <br> <arg1> <br> <arg2> <br> ... <br> $end \
<br> The args will, of course, depend upon what the Command is. </li>
</ol><li>We are not developing client and testing our functionalities using \
telnet.</li><li>Once core daemon and client interaction part is done we are planned \
to start working on HubConnectionlistener and Core Action Part.<br>
</li><li>We have already developed and designed some part of it which can be viewed \
at <a href="http://github.com/jrharshath/xdc.">http://github.com/jrharshath/xdc.</a><br><br> \
So looking for the comments on the project and if KDE developers are interested then \
I would request interested developers to mentor us in GSOC10. Then we will decide our \
solid boundaries for this GSOC10 and can take this further.</li>
</ol><br>Thanks & Regards,<br>GAURAV GUPTA<br>B.Tech IV Yr. , Department of \
Computer Science & Engineering<br>IT BHU , Varanasi<br>Contacts<br>Phone No: \
+919236964262<br>e-mail : <a \
href="mailto:gaurav.gupta.cse06@itbhu.ac.in">gaurav.gupta.cse06@itbhu.ac.in</a><br>
<a href="mailto:1989.gaurav@gmail.com">1989.gaurav@gmail.com</a> <br><br>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic