Outline · [ Standard ] · Linear+ Webserver with Ajax and XML

[Fuxie - DK]

But then,what is there to test for us??

[Darklord]

But then,what is there to test for us??

In particular in your case, two things:

1. Compare the prepare times of each kind of request (XML and normal), to have an ideia of the savings we can expect; this may also help in searching for ways to improve the webserver itself.
2. Verify if the xml sent is valid; the browsers will complain if its not; some exotic file and client names may screw this up, and with a long list of files and clients like yours, the change of something going wrong is greater, and consequently faster to solve.

This post has been edited by Darklord: Jun 6 2006, 18:34

[Fuxie - DK]

It's, from my PoV, next to impossible to compare preparation times, when you have split up the pages...

For us to test times, the XML-preparation should generate the same data as the links in XP (or Light) template...

If it doesn't generate the same, it's like comparing apples and bananas..

[Darklord]

It's, from my PoV, next to impossible to compare preparation times, when you have split up the pages...

For us to test times, the XML-preparation should generate the same data as the links in XP (or Light) template...

If it doesn't generate the same, it's like comparing apples and bananas..

True, to some extent, and im working on that (requests combined).

However, the information sent will always be diferent, since the approaches ARE different, thats the point

[Fuxie - DK]

First click on "Transfer" after login should be the same every time (not considering that data have changed a little), wether it's XML/Ajax or "old way"..

But if the XML-processing created everything that Transfer Page does ATM we have something to compare against, when talking about time..

[Darklord]

First click on "Transfer" after login should be the same every time (not considering that data have changed a little), wether it's XML/Ajax or "old way"..

Not necessarily, depends on the approach, if we go ajax all the way or not.

I prefer not to, so i agree here.

But if the XML-processing created everything that Transfer Page does ATM we have something to compare against, when talking about time..

It will, or at least i think so.

Some things may need a diferent approach, though.

[Fuxie - DK]

Ofcource, Ajax is all or nothing...

But in the conversion process, you'll have to make one thing/page at a time.

And until we can click a link that creates a visual page that creates the same in Ajax and "old way", it's not possible to determine wether there is an improvement or not.

[Darklord]

Ofcource, Ajax is all or nothing...

No, thats one of the biggest mistakes that may be (and are being) done.

Both systems can and should coexist, thats one cardinal rule i learned in my studies of the tecnique.

New tecniques are always abused, used even when shouldnt; but thats the way to advance in this field.

This post has been edited by Darklord: Jun 6 2006, 19:10

[DonGato]

Well, the style will be kept but the data will be managed with AJAX. You're heading to that Darklord?

[Darklord]

For now, im just working on the updating part, and trying to avoid a lot of changes on the way it works already.

However, i foresee some problems, namely the tooltips; a request for update on each mouse over definitely isnt a good ideia, it may need some changes with that.

After having a working solution, we may think of better ones.

[DonGato]

Well, some data we have from other parts of the code and we can reuse (but it might be complex as we construct the strings on the server side), and we can implement something like the GUI delay. Currently we show it immediately when mouse over and sometimes that is really disturbing.

[Aw3]

Yep, and that is also one of the strong points of the ajax way, since it doesnt reload the entire page, just the changing bits.

How does the server know what to resend? Do you keep the copy of everything transferred to a client?

New tecniques are always abused, used even when shouldnt; but thats the way to advance in this field.

We are not commercial -- abusing here is not allowed ...

[Darklord]

Yep, and that is also one of the strong points of the ajax way, since it doesnt reload the entire page, just the changing bits.

How does the server know what to resend? Do you keep the copy of everything transferred to a client?

It doesnt.

Its up to the client to decide what and when to ask, and what to do with it once it arrives. Its a pull strategy instead of a push.

There are techniques for the server to push info however, like an emergency of some sort.

[Darklord]

Im suprised noone has commented on this:

As the webserver as it was couldnt serve XML, i made the necessary changes (an ugly and imcomplete hack, the webserver needs serious refactoring); when done, it hit me with the new possibilities of this new interface:

- possibility of any XML aware program being able to monitor and control emulePlus easily; this includes IM programs, IRC programs, scripts, whatever...

I think this is a very useful feature. To give a better ideia, i implemented another prototype, this time a Yahoo Widget, that can monitor eMulePlus through the XML interface.

You can get it here. It needs a new executable, that has the xml login implemented, which you can get here.

Implementation Notes

I needed another, webserver non-related, way to test the XML interface, to show issues with it that couldnt appear working only on the webserver.

Like i refered on the first post, a lot of possibilities exist, but i wanted to try working on another cool thing; the widgets are promissing and popular, so i decided to try to build a widget that could do the same as the prototype for the webserver client.

Got the documentation and gave it a quick study; the widgets are javascript and xml, so it was easy to get it.

Looking through the widget gallery, i found an already existing widget, Emule Stats, that did all that i intended, only getting the info from the online sig (doesnt work with eMulePlus, because of diferences in location and format).
I looked through the code (its a small widget), added and changed what was needed; even reused some of the code on the template

One of the issues i talked about that i had already identified was the login, a way was needed to send the session id to the application, so that it could use it in the other requests; it isnt needed with the browser, as it already has one, but essencial for other applications.

I refactored the code of the webserver, moving the login procedure out of the processUrl() method and into one of its own. Then i added the rest of the code, to implement a request for login in the xml channel.

The request is this:

CODE

http://[webserver url]/?channel=xml&request=doLogin&p=[webserver password]

Given the way that the webserver can process both GET and POST http methods in the same way, the above GET method works. However, its recomended that a POST is used in this case (as its implemented in the widget).

The widget just uses the getStats request, same as the template as it is today.

Widget instructions
To use the widget, you need the Yahoo Widget Engine.

After each launch, the preferences window appears; configure the webserver url and password fields correctly.

After, it will try to connect to the webserver, if a problem with the connection occurs, an alert dialog box will appear. If such happens, you will need to restart the widget, as i didnt include a login button

This is just a prototype to show the possibilities i talked about; later i intent to add more functionality as it is implemented in the webserver.

[Aw3]

Yep, and that is also one of the strong points of the ajax way, since it doesnt reload the entire page, just the changing bits.

How does the server know what to resend? Do you keep the copy of everything transferred to a client?

It doesnt.
Its up to the client to decide what and when to ask, and what to do with it once it arrives. Its a pull strategy instead of a push.

You were mentioning all the time that only changed fields should be retransmitted. How can the client know which fields changed?

Im suprised noone has commented on this:

As the webserver as it was couldnt serve XML, i made the necessary changes (an ugly and imcomplete hack, the webserver needs serious refactoring); when done, it hit me with the new possibilities of this new interface:

- possibility of any XML aware program being able to monitor and control emulePlus easily; this includes IM programs, IRC programs, scripts, whatever...

I think this is a very useful feature. To give a better ideia, i implemented another prototype, this time a Yahoo Widget, that can monitor eMulePlus through the XML interface.

Usually it works in the following way -- the more "useful" features you have, the less security you provide...