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

I prefer not to, so i agree here.


It will, or at least i think so.

Some things may need a diferent approach, though.

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.

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.

Well, the style will be kept but the data will be managed with AJAX. You're heading to that 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.

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.

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

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

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.

Im suprised noone has commented on this:



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:



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.

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

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

Where did i said that?

What i did say was, what is transmited is the data, what CAN change.

Take a look at the requests i mentioned, call them on the browser. That is what its transmitted.

The structure of the document wont change (much), at least while you are in a page, so there is no need to send it every time.


Perhaps.

Should we not implement anything else then, with fear of that? Or should we try to think ways to avoid most problems and attack vectors, while implementing new features?

Why even use a tool thats connected to such a dangerous thing as the internet? Better to just unplug that cable

EDIT: as for this feature, it just uses the same mechanism of the webserver. If there is a an attack vector in it, theres probably also in the already existing webserver.

Unless you mean the other programs, and that is not our concern.

It's pretty hard to find the boundary between what is changing and what is not. For example, the list... its length can be different on every update. Another example is localization -- currently a user can change language any time and the page will be updated.

So is better to do the localization on every call instead of allowing to update such things by forcing a reload of the page?

Is better to transfer all HTML tags, formatting and transmitting the HASH 5 times with each page instead of only requesting the data that is the only thing that effectively changes at the server side and use it properly at the client side?

Now when you sort by a column the GUI has to reprocess all the data and send it again. With AJAX you do it at the client side, no transfer, no server processing. When you add a file you have to reprocess all the list. In this case you can add the data of such file to the list (of course we would like quick updates over the list so this might not be used in this case).

Hope you get the idea this way: with AJAX you have a Web client that is loaded in the first connection, and then only XML with data is transmitted at client request. Of course I would prefer to use an optimized format instead of XML but standards...

Actualy, thats pretty much what JSON is, and its getting to be a standard, but then you cant do the things like the above as well.

Anyway, its used a very simple form of xml anyway, without many of the complexities of the format.

Another example of such an implementation of a XML interface.

As i have been told i have no suport from the eMulePlus team to implement some necessary refactorings to the webserver, needed to sucessfully implement this feature, which implies a lot more changes to the way the webserver works, im scrapping it, and stopping my contributions to this project and the associated mod, since i see no future in Plus.

On a final note:

Ive already noticed this disturbing trend of yours (the EmulePlus team) of fear and loathing of change and improvement; happened with secure identity, which you fought to the last moment to include until you were forced to, its happening with Kademlia and protocol encription, and now this, with the refactoring of a broken design (which isnt even in the same degree of complexity of those two).
All are solutions to existing problems, which you choose to address by stinking your heads in the sand, despite all the requests (and offers) for it.

Any change or feature can brake the program; each is tested beforehand, but if something slips and it gets broken, its fixed, its not like its something permanent and imutable, with disastrous consequences.

I need this refactorings to successfully implement the ajax feature; however, they are beneficial to the code base by themselves, so ive been posting them.

However, if i have no suport for it, then there is no point, is there?

Open Source projects thrive by the contributions of all; if however, you, as its team, dont foster them, by considering, commenting and embracing changes for the better, then i see no future in your project, particularly since you drifted so much from the code base of the oficial that you cannot easily integrate the progress that occurs there, as can others; a clearer design could help, but you dont want that either, apparently.

As such, im giving up on contributing to this project, and since i see no future in it, will also give up on the mod based on it, and recommend its retiring, since the trouble of integrating new necessary features and changes into it and sync it with your codebase will not be worth it, as there are other, possibly better codebase alternatives (we have a client based on ZZUL codebase, maybe they will be more open).

As a user, im also leaving Plus, since without the work i put into it, ive no motivation to stay with it, as there are other clients that implement pretty much all the features i like in Plus, and have others that you dont, and dont appear to want to implement, clearly they are more open to change and improvement.