3/15/2002 07:22:00 PM
Metaphor
Using this application is like being able to copy stuff from one computer and paste on another computer. Need we say more??
posted by dJsLiM | Link | Edit
3/15/2002 06:58:00 PM
Story
Here is a revised/augmented story that we have produced at tonight's planning game meeting. The first two are the ones we will tackle first and foremost. Enjoy!
Number in parentheses are estimates.
- I want any peer to be able to retrieve a list of things I can paste from a selected remote clipboard peer(2)
- I want to be able to specify the remote clipboard peer from which to retrieve pastable data. (2)
- I want the peer on the receiving end to cache recently downloaded data. (1.5)
- I want the peer on the receiving end to decide what to paste as well as what data to download for pasting(1.5)
- I want the application to provide feedback on the transfer of data from the remote clipboard peer if it is going to take more than a second (2.25)
- I want any given clipboard peer to be able to notify other interested peers of new data availability (1)
- I do not want the application to effect the content of the local clipboard (1)
- I want the application to keep a log of all the events (1.5)
- I do not want things pasted to have any effect on the local machine. (1)
- I want to just CTRL-C on one computer and CTRL-SHIFT-V on another and have it work as if it were a series of CTRL-C and CTRL-V operations on one computer. (3+)
posted by dJsLiM | Link | Edit
3/13/2002 04:08:00 PM
As a reminder, here are our original coding standards documents:
Python
- coding standard
- example py file
C
- C-specific standards inherits the rest from python style elements
- example c file (NEW)
- example h file (NEW)
posted by dJsLiM | Link | Edit
3/11/2002 03:42:00 PM
** CLIPSTER **
on-demand stateless "P2P" clipboard
client platform
win32 - clusters have MS Visual C++ (if you want mingw32 then we could talk about it)
language
python and probably C for the system-dependent layer. We can pacakge up the end product as a stand-alone executable and even create an installer and distribute it!! :)
protocol requirements
- must use a subset of HTTP 1.0 -> easier to use proxies behind firewall
- must use layer-based implementation
- data retrieval layer
- can later be extended to use whatever stoarage mechanism other than the file system used initially
- protocol layer
- originally understands HTTP-GET and HTTP-POST
- can later added authentication like HTTP-AUTH challege here
- important to communicate protocol version being used on client/server so they know how to dumb down or smart up. (using the HTTP_USER_AGENT header)
- the copy/paste layer
- system dependent implementation could be plugged in
- we'll embrace all opens standards such as RDF and MIME whenever possible.
story
- I don't want stuff I paste to have any effect on my computer. It should work identically as your normal everyday pasting. (i.e. you may always paste malicious file/code, so long as you don't execute it )
- I want to just CTRL-C on a computer and CTRL-SHIFT-V on another computer and it should work the way CTRL-C and a CTRL-V on any one computer does.
- I want to be able to specify the remote server from which to retrieve stuff from
- I want the client to decide what to paste.
- I want the server to let the client know when there is new stuff that can be pasted.
- I want the clipster pasting to NOT erase the stuff that is already in the local clipboard.
- I want the client to be able to retrieve all the list of things I can paste from the server.
- I want clipster to provide user feedback on the transfer of data from the remote clipboard server to mine if it takes more than a second.
scope
The project would be considered complete if:
- I do CTRL-C on computer A
- I do CTRL-V on computer A and pasting works as expected on files, text, etc.
- I do CTRL-C on computer A
- I do CTRL-C on computer B
- I select the remote clipboard server to computer A
- I do CTRL-SHIT-V on computer B and pasting works as expected on the stuff copied in step 3
- I do CTRL-V on computer B and pasting works as expecte on the stuff copied in step 4
- everything else involves policy decisions and other stuff that is out of scope
some implementation detail ( a brain dump, nothing is set in stone per XP's no up-front-design guideline )
- notice that you do plain CTRL-C when copying. This allows the person using the computer to copy something into his/her local clipboard and paste it for his/herself using CTRL-V and at the same time allow other people to use CTRL-SHIFT-V on their machines to paste from this pasteboard.
- every CTRL-C operation results in a system dependent grabbing of the "target". It may be a file path, text, etc.... and it gets put in to a local directory known to the clipster. If multiple clipboard formats can be provided, it might create a directory with those multiple clipboard formats as separate files? That means there can be at most 1 level of hierarchy under the root
- every SHIFT-CTRL-V operation results in GET request to the clipster server's root which will return a listing of what's available (maybe use RDF?). the client will sort it by date created. Of course one can imagine a situtaion where you simply grab the directory listing and let the user decide which one to paste. perhaps a SHIFT-CTRL-W ? This would require some sort of a GUI.
- actual pasting happens by first creating a backup copy of whatever is in the real clipboard, then putting either the latest copied item or the selected item from our clipboard into its place then following through with the actual paste.
icing on the cake (out of scope, but would be nice to get done if we have time)
- GUI for setting preference
- where to put the copied items
- how many items to keep
- which port to use
- limiting file size
- forcing only certain types of pastes (i.e. text only)
- add/remove/edit authenticate users
- set policy on what to do about stuff that got pasted from the clipboard (would it get deleted?)
- tray icon
- right click for preference
- organize clipboard servers (kinda like having favorite clipboards)
- support for authentication via simple HTTP-AUTH
- SSL tunnel
FAQ
- Why can't I just use IM?
You could. But, then you'd have to create multiple accounts, open a message box to "the other" you, copy/paste or drag/drop the file. receive on the other end, then look for the file. in our case, you CTRL-SHIFT-C then CTRL-SHIFT-V on the other end. also, you may have difficulties using file transfer behind firewalls.
- Why can't I use ftp?
You could, with difficulties behind a firewall. not to mention you need to set up an ftp server and a client on both ends, put things in places, retrieve from that place, etc... we just want to make it really simple.
- Isn't this just a glorified web browser and server combo?
Hmmm.. it's more like a dumbed down http client/server combo. yes.
- Stateless? are you nuts? That's gonna be butt slow for TCP!
Well, have you tried doing a telnet to a webserver and just typing GET / HTTP/1.0 followed by double carriage returns? Do you see how fast you get a response back? I think that's fast enough for us. Being stateless rids of a lot of burden for the end client and server thus decreasing complexity not to mention increasing scalability (we're not particularly worried about scalability, though).
posted by dJsLiM | Link | Edit
