To make this sane, we should limit the scope of data types handled. a generic upload/download probably is going too far for now as we want to be able to have "Thumbnails" and these are differently generated between Themes and Wallpapers, and Config profiles would have the ability to add .desktop files for them with an icon selected etc. - so each type is a bit different. Also searching, listing and so on will vary.
To define some terms:
This means files are uploaded to your account on exchange but are private. Merely modified time stamps are kept and all your exchange using clients connect and listen for change notifications. When 1 client uploads a new file/config all clients get the change/add/delete and then "implement" that change locally (download a new file, delete the wallpaper, download updated config and apply it etc.).
This means to not just upload for Syncing, but also make it available to share to others so they can download and add to their own collections. Such files/data need to probably be copied to a public repository to allow the original uploader to delete their own copies but not the public ones (but allow separate control over the public ones they shared out originally if they want to remove it from the public - but to make it an extra step to do that).
As we are only manipulating eet content, Exchange could add a special section in each eet file that it does upload to store extra data. Like tag, reference website, flattr, things like that. The thumbnail could also be generated on the application side and put in with an expected name.
- Sync/upload and share
- Wallpapers (~/.e/e)
- Themes (~/.e/e)
- Config profiles (~/.e/e)
- Order files (Bar, Menu, Start etc.) (~/.e/e)
- Modules (~/.e/e)
- Icons (~/.e/e)
- Fileman favorites (~/.e/e)
- Fonts (~/.e/e)
- App desktop files (~/.local/share/applications)
An Azy server will be implemented using https (probably with a cert) which will automatically manage http session/authentication for clients. Clients will send/receive content using this server after they have logged in, so we'll need to set up some sort of storage for accounts and settings. Best guess is this will require some sort of eet structure on the server end to manage the accounts securely.
Exchange should be the wrapper for Azy which simplifies sending/receiving data (handles all eet compression of data, for instance), notifications, getting status, listing personal and shared/public items, fetching and caching "preview thumbnails" and other text etc.
It would be cool, if the server was included in the client library itself. This way, it will be possible with an UPnP or a ZeroConf protocol to announce on the local network that service publicly. The main point is that sharing content doesn't require you to share it online at all. You show the nice theme to your friend, they like it, they get it from you directly and instantaneously, later they can flattr it ! Completely distributed AppStore model. True freedom.
Start it all by re-doing exchange library, then making some cmd-line test apps to make sure it can all work. keep them as part of libexchange for future testing and tools. now make some elementary clients to do some of the above.
The server part will be splitted in two part, the Azy/efl one, that does handle the upload interface and front end to serve all the available files. The idea is that the front end could be easily duplicated as it only serve static file and it could be rsynced when needed. This will provide a really scalable solution to this project.
The first module that would be interesting and easy to do will be the wallpaper module. Then theme for E17, Elementary and also apps like Terminology.
The server must never store any private information. Authentification would be just profivided by an uploaded public certificate that will be used to sign all eet file by the client before being send. Every transaction will be signed. Each eet file should be properly tested before being made publicly available in an sandbox. That mean fork/chroot and loosing as much priviledge as possible before opening the file and trying to analyse it. The analyse step beyond eet_open, is left to a different test per content. This step could also produce the thumbnail.
Finally all transaction, including key management, will require to be logged. Time, IP adress and associated public certificate should always be tracked for every transaction. Later we will need a way to automatically block all content linked with one IP adress or a range of them, same goes with a specific signature or a combo of them.
As we don't have a team of people payed to cleanup this user produced content, we need a way for all people using Exchange to report abuse and issue that would be automatically put into a specific container directory. Some content will be protected from this crowd (typical use case, a wallpaper from a soccer team would be wrongly flagged by the opponent). So their is a need for an administration interface (could be a command line tool).
Imported from https://trac.enlightenment.org/e/wiki/Exchange
1 zmike 2010-12-03 23:15:11
2 raster 2010-12-04 18:42:28
3 zmike 2010-12-04 19:24:35
4 cedric 2012-03-10 05:23:39
5 cedric 2012-03-10 05:24:13
6 cedric 2012-07-10 04:00:34