Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[zenria]

Hi,
I open this thread because I wanted to modify the web interface of amule, and i found the aMule.tmpl file really awfull... I can change the basic layout of pages but it is not sufficient. Some parts of the interface are hardcoded in WebServer.cpp (eg: action links pause,resume, cancel, up, down...)

I think the current release of amuleweb is mixing the presentation part of the GUI and the production of data. For exemple, it would be nice to have an amule deamon implementing itself a SOAP server. Then, it would be very simple to write a client (web or other) for displaying and managing amule data.

Did someone though about this orientation ?

[lfroen]

I am interested in your idea. And I agree that web interface could be match better. Unfortunatly, I have no idea about "what is soap, how does it work, and why it's good".
It would be very nice of you to cooperate some more:
* Contact me personaly on lfroen@amule.org
* Post here explaining technical details

Thank you.

[ken]

SOAP is Simple Object Access Protocol.  It's a variation of XML-RPC.  Sound familiar?  

[lfroen]

I know how to use google, thank you. I would like to hear technical explanation about "how to deploy it here" and "why would I do it".

And no, it's not sound familiar - that's why I'm asking.

[Kry]

oh PLEASE. RPC discussion again?

[lfroen]

No, Kry, that's not RPC. I'm looking for ability to write webserver in some "web" language - php, perl, .net ... SOAP is simple text based (xml inside) protocol afaik.
May be it will serve the purpose.
Please, don't start with "we can do it in amuleweb". Yes, we can, even in assembly, but the thing is - it's not the best way to develop web-based applications. amuleweb must dramatically improve, and I'm looking for a way to it. Simple cpp coding not gonna do it simply as that.

[ken]

Originally posted by lfroen
And no, it's not sound familiar - that's why I'm asking.

I only meant: it's RPC -- again.  It's one of the options I looked at before coming back and admitting to being on crack.  

The main benefit of SOAP as an RPC mechanism is flexibility.  It is, as you say, a simple text protocol so that there are many ways of implementing clients.  Plus, it's a standard with support in the libraries of many toolsets, so for some toolsets (Perl, Python, Ruby, etc.) it's very, very simple to implement clients.

So, depending on the RPC capabilities that amuled would hypothetically expose via SOAP, it satisfies zenria's goal of being able to customize the web front-end more completely.  If there's a decent C++ library, it may also relieve some of the tedious, error-prone hand-coding of EC support for each new feature.

However, I don't think it satisfies the goals of making for a more efficient protocol for a more responsive amuleweb.  I also don't think it helps to implement high-bandwidth stuff like sources listing in the remote clients that made you consider merging amuleweb into amuled.

[lfroen]

Ken: following our discussion on irc - my idea is to have webserver written on one of managed languages (didn't choosen yet). This will enable usage of dedicated web-design  tools to make amule page look pretty and more functional.
It will require amuleweb being generic webserver, able to run this specific magaged language; written here or taken from third side.
IMHO apache is too match overhead here, both in resource usage and in management complications. But, there're many light weight webservers over there - and we may choose just to import code from one of them.
amuleweb already have basic request parsing, it may be possible to add language interpreter. I would really like that option.

[Kry]

Originally posted by lfroen
No, Kry, that's not RPC. I'm looking for ability to write webserver in some "web" language - php, perl, .net ... SOAP is simple text based (xml inside) protocol afaik.
May be it will serve the purpose.

Hum, it's a variation of XML-RPC, so it's related to RPC

Anyway, I still can't understand the conenction between a text-based information exchange protocol and rewriting the webpage on a "web" language.

BTW: you can't rewrite the webserver into a web language afaik. A webserver is something used to well, serve pages. you know, sockets and stuff.

[zenria]

Some technical precision on SOAP :
Yes, SOAP is a RPC protocol, it can be implemented in amule via a powerfull and multiplatform library called gSOAP (http://gsoap2.sourceforge.net/). The implementation of RPC mechanisms would be very simple (see the samples of gSOAP).
Since it is HTTP/XML based, amuleweb could be written in any language that has libraries to deals with these protocol. (and in any language where a SOAP library exists )

However, I don't think it satisfies the goals of making for a more efficient protocol for a more responsive amuleweb. I also don't think it helps to implement high-bandwidth stuff like sources listing in the remote clients

It can help too : gSOAP use the HTTP protocol for handling SOAP messages so it can gzip a response as every web server can do.

It will require amuleweb being generic webserver, able to run this specific magaged language; written here or taken from third side.
IMHO apache is too match overhead here, both in resource usage and in management complications. But, there're many light weight webservers over there - and we may choose just to import code from one of them.

Why reinventing the wheel ?
There are so many well proof webservers that can run many scripting languages. In fact, when you want to run amule in deamon mode (amuled+amuleweb), in most case there is nto only amule that runs on the box. Personnally, i am running amule on a K6-233 64Mo server with an apache webserver used to serve some https pages.
And for me, the ability to embbed amuleweb in apache would be very nice.

[Kry]

Uh... do you guys fail to realize that amule still serves the data to other apps via ECv2 and it's not an option to make amule full of information interchange protocols to deal with other stuff, not to mention we already had this RPC discussion a lot of times?


I mean, you guys are talking about adding another lib to amuled? And another info interchange protocol with it's underlaying code to deal with it, duplicated from the ECv2 handling?

[Kry]

Oh, not to mention we already have problems (speed problems) interchanging binary and compressed data from amuled to amuleweb, I don't think gziped text-based protocol is an option at all

[zenria]

Originally posted by Kry
Anyway, I still can't understand the conenction between a text-based information exchange protocol and rewriting the webpage on a "web" language.

For rewriting the pages you could use any language running on any webservers you want and not only amuleweb.  In amuleweb the web server and the web application are the same thing. I think this is not a long term solution.
In my mind, the business part (amuled) and the presentation part (the web pages, amulegui...) of amule should be dinstinct.

[Kry]

Originally posted by zenria

Originally posted by Kry
Anyway, I still can't understand the conenction between a text-based information exchange protocol and rewriting the webpage on a "web" language.

For rewriting the pages you could use any language running on any webservers you want and not only amuleweb.  In amuleweb the web server and the web application are the same thing. I think this is not a long term solution.
In my mind, the business part (amuled) and the presentation part (the web pages, amulegui...) of amule should be dinstinct.

Uh... I am starting to realize why you are having this discussion.

a) "In amuleweb the web server and the web application are the same thing"

No, they are not. The web server serves web pages, there is a module inside that reads the template, changes the "tags" there to their data content, and that's all. The webpage is a html template, where you have some tags that are changed by amuleweb to their amule data.

b) In my mind, the business part (amuled) and the presentation part (the web pages, amulegui...) of amule should be dinstinct

... aren't they? they are named "amuled" and "amuleweb" and "amulegui", they are separate programs that comunicate one with another via ECv2, and that share no code except for some bits for EC handling and other functions.

I think you're missing that fact. amuleweb is ALREADY splitted from amuled.

[GonoszTopi]

Just some side-notes to conversation:

First: scheme is: [web browser]<----HTTP---->[web server/ECv2 client]<-----ECv2---->[aMule(d)]

It seems to me that we are now talking of separating the web server and the ECv2 client, beacuse aMule(d) will NEVER support any other data exchange protocol than ECv2 (well, not talking of ed2k). The only exception from this rule might be ECv3.

Benefits of separation:

• You get a proven good-working webserver, with full set of features

Backdraws:

• If ECv2 client is written in a web language, e.g. PHP: It has to reconnect/re-authenticate to aMule at least at displaying each page == waste of bandwidth.
• If written in a high-level scripting language, e.g. perl or python: speed and memory reqirements problems

The only reasonable solution to me is writing a module/plugin/etc. to some web server, but I don't really think we would benefit too much of this but learning how to write modules/plugins/etc.

Any other ideas?

P.S.: Why haven't I seen any posts yet saying 'I have implemented a new webserver/apache module to ECv2/anything and want it to be included in CVS'?  :P