Feature #1360

Proxy Api/Client

Added by megabitdragon about 8 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:



What is the point of having a separate class for detecting the mode (local/remote). Since the calls are made to the PFE api endpoint I would say it should belong to the Server api/client (maybe name this PFEApi). This will keep it consistent with your architecture blueprint.


#1 Updated by ming about 8 years ago

  • Status changed from New to Closed

Just merged them. I split them before to keep separate but keeping together makes more sense in a perspective.

#2 Updated by megabitdragon about 8 years ago

  • Status changed from Closed to Assigned

Please make the changes in the api as well for consistency.

#3 Updated by ming about 8 years ago

PFE API != Relay API. At least it is not clarified that the PFE server can operate as the Relay server and vice versa. Actually in such case there is no point in establishing connection using PUT /client, because we would know PFE address for remote access and local address is contained at the GET /servers result. This is why I see the point in unifying the client and not the API. Or maybe I just don’t understand something.

#4 Updated by ming about 8 years ago

Look at the bug #1218 as well. My point is to keep the PFE API for determining addresses and the Server API for operating shares and files.

#5 Updated by cpg about 8 years ago

i did not look at the code, so i cannot make any assertions of what should be done.

but i will clarify that the PFE and the relay are different. they happen to be in the same machine at the moment, but we absolutely 100% do not want to rely on that, or it will be a serious problem if we were to hit some scale/load issues.

#6 Updated by megabitdragon about 8 years ago

  • Status changed from Assigned to Closed

After Carlos' comment I agree that PFE should be separated since there will always be a single call to it (e.g. PUT /client).

Also available in: Atom