Log in
Forgot your password?
History for ClientInteraction
??changed:- ClientInteraction Goal Gideon shouldn't mandate client implementation decisions, it should be adaptable to client needs. Gideon should offer flexible accesss to different sets of metadata (see MetaData for further discussion). Thoughts Probably the only hard requirement that i really want to push for client interaction is that the server should support replying with a full dependency list for a package. for example package foo has dependencies a,b,c. and package b depends on package e and f. the client should be able to expose the depedency list a,b,c,e,f in a single interaction with proper nesting. hmm... if a depends on b. then it should get installed after b (obviously) but this again requires proper nesting for dependencies if this information is to be conveyed in a single response. hmm... is the above realistic?, probably not, the alternative is having a client required to download separate metadata files for each depedency and than organize them in a graph. actually pushing this to the client makes alot of sense. the client knows best what the installed packages, the server would have to make exhaustive lists otherwise. See GideonProtocols for server exposed protocols that clients can use. <hr solid id=comments_below> Zen (Mar 13, 2002 8:08 pm; Comment #1) -- If the only protocols that a client can talk to a master server is HTTP, HTTPS or FTP, then you have just increased the number of possible mirrors by a factor of 1000 (as they can simply mirror a master repository using wget or similar). This puts more intelligence on the client, but also allows for distribution of packages using such means a CDROM of even floppy disk, as the client just needs to be pointed at a URL that is the repository. This puts the burden of searching and dependancy generation on the clients, but if this is an issue then a gideon_client.py module could be shared amonst all that are developed (although only one is needed, and is probably called distutils).