Concepts

From PhexWiki

Contents 1 What does a GUI need from a backend? 1.1 Basics 1.2 Searches 1.2.1 Licenses 1.3 Data from the network 1.4 Data from Downloads 1.5 Data from search-results 2 Usecases for an API 2.1 roleplaying program - finding people, finding maps, finding places, finding objects 2.2 Codesnippet-finding 2.3 Other applicatios

This page is dedicated to ideas about possible futures of Phex. Only some of the things in here wil be in Phex someday, but all of them will help to improve Phex, because they help to spawn more and hopefully new ideas. Definitely open for discussion! - Arne

What does a GUI need from a backend?

Done for a general GUI for different possible backends. -Arne

Basics

It needs to be able to

• Do searches/queries (for example directly magnet based: They can query by keyword ("kt=") and by hash ("xt=urn:sha1") and by both).
• See search results (per query)
• See a list of running searches
• Get network-status
• Connect and disconnect
• See and modify downloads
• See and modify uploads
• Get Statistics
• Get ID and description of the Core

Some other things which would be nice:

• What happened/which new things are avaible since last connection between GUI and Core.

Searches

A search-request needs to be able to contain

• An ID (number)
• a search-type (query, what's new?, browse host, ...)
• A simple text (simple search)
• a reg-exp search (for possible future features)
• An IP for browse-host
• metadata
  • name
  • artist
  • license
  • ... arbitrary
• hash
  • sha1
  • TigerTree
  • ... arbitrary as by magnet

Some of this information could be transferred in a magnet:

• name + hash

Licenses

Need a generalized format by which known and new licenses can be parsed.

One example is CreativeCommons RDF: Markup description - Wrappers

Data from the network

Data which the network could deliver:

• Contact:
  • address: IP, ...
  • ID: name or GUID
  • connected: bool
  • connect-time-ms:
  • online-time-ms: time the client knows that the network-connection is life
  • node-type: supernode, leaf, shielding node
    • node-type-name: ultrapeer, leaf, push-proxy
  • nice-name: a name, selected by the user.
  • region: country
    • city:
  • program-info:
    • name:
    • version
    • system:
    • language:
  • crowd: tags by which the network could be organized.

• status
  • connected: bool (see contact)
  • number-of-live-contacts: number of active peer-connections
  • connection-quality: not connected, weak, good, great, exceptional, connected (in case no descriptive status can be set)
  • connect-time-ms: see contact
  • onlince-time-ms: see contact
  • firewalled: yes, no, unknown

Data from Downloads

• collected-download-speed-KiBps
• number-of-downloads
• number-of-active-downloads

• download (for each)
  • file
    • file-name
  • size-bytes
  • metadata
    • arbitrary
  • hash
    • sha1
    • TigerTree
    • ...
  • number-of-sources
  • number-of-active-sources
  • source (for each source)
    • address
    • name (see network: contact)
    • download-speed-KiBps
    • firewalled: yes, no, unknown
  • status: active, waiting, inactive, finished
  • progress: 0 ... 1
  • parts-completed:
    • ordered list from 0 to 1 (would a list with the KiB be better?- Arne)
  • searching: bool
  • local-file: where the file gets saved
  • temporary-file: where incomplete version is saved, as string, maybe with "*" as wildcard or using reg-exp to point to multiple files.

Data from search-results

same as for a download, but additionally:

• status: started, running, stopped, finished
• progress: 0 ... 1

Usecases for an API

roleplaying program - finding people, finding maps, finding places, finding objects

Imagine a roleplaying program which utilizes Phex.

In conventional programs all runs over a central server. People log on and off regularly.

Now I want to find some people who are interested in just going adventuring.

The program now needs to be able to tell the Core to connect and found its own small network (minimum data for this: first IP/gwebcache, network-name).

Then it needs to be able to define some kind of data, which can be searched for.

With this data, people now advertise their interests.

Now the program needs to be able to start a search.

Results could be, for example, people who want to do one-on-one battles, people who want to join a group of adventurers in the search for the dragon scale on the black hills, people who seek for other people who want to join in their quest, new maps, and much more.

Then the people connect, and the network did what it was designed for.

This could also be used to find opponents and partnes for any game.

Also it woud be a good playground for a search-program which connects real-life situations and sales (for example using ripple for p2p payment), because bugs (which always exist) aren't as severe in an rpg as in hard real-life.

Codesnippet-finding

Another idea would be to create a program which allows developers to annotate their codesnippets and which shares those snippets to the worls, which are licensed under free licenses.

Programmers could then search for snippets by keyword, language, license and author(s).

For this, a code-editor should be able to just call on Phex to connect, tell it what to share (either the files, or directly the data including additional data which need not be files), and fire searches.

Other applicatios

• A Job-Portal