> > c. Each of the above folders is a virtual directory, with mashups > > available from the urls http://<domain>:7762/system/<mashup > > <http://%3cdomain%3e:7762/system/%3cmashup>> and > > http://<domain>:7762/samples/<mashup > > <http://%3cdomain%3e:7762/samples/%3cmashup>> respectively. > > > The virtual directory can simply be a location where the deployer will > poll for scripts to deploy/update. However, since each mashup is > essentially just a service to axis2, it will make the service available > at /services/<mashup>. Since it is not possible to have a service name > with a slash (/), and axis2 currently does not have a concept of a > service hierarchy, we will have to come up with some namespace > mechanism > to differentiate between two services with the same service name > (channa/sudoku and jonathan/sudoku).
You mean we'd need to do some front-end rewriting of the url: /jonathan/Sudoku to something like /services/jonathan;Sudoku ? Or we'd have to actually work at building a service hierarchy into axis2? It's too bad Axis2 is limiting us here, but I just can't see scaling a mashup community site to a large number of users with a single name space for the mashups. > > f. Administrator username/password, virtual directories, and any > other > > user preference information must be persisted so they are protected > > against Mashup Server upgrades - e.g. local settings or preferences > > file, Registry, etc. > > > We are thinking of the possibility of keeping the information to be > persisted across upgrades within the installing user's home directory > in > a given operating system (e.g C:\Documents and Settings\<installing > user>\system or /home/<user>/system, similar to the approach taken by > maven. Ideally all virtual directories should fit into a known > structure > within this root, so that the deployer would not have to recursively > search through an entire hierarchy of directories for scripts to be > deployed. Alternatively, if the option to arbitrarily locate virtual > directories is required, the deployer can be provided a list of > directories to be polled, with an entry being added to this list each > time a new virtual directory is configured. I was thinking that we could use one of the (many) standard mechanisms for storing preferences. In windows there is of course the registry, or even better there is Application Data and Local Settings folders associated within each folder, where we could store a file containing the persistent information, including a list of paths to virtual directories. This is somewhat protected from user meddling. It's not nice to force all virtual directories to be in one location, as the user may be defining his directory structure for other purposes (file sharing, backups, project-based structure, etc.) which would conflict with the structure we impose. I don't see it being very much harder to store a single virtual root directory persistently than a list of arbitrary virtual directories. _______________________________________________ Mashup-dev mailing list [email protected] http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
