Provisioning component for Revo

Guys, your thoughts on something like this.

I’ve spent the past few days putting together the bones of a revo 3rd party component I’ve called Provisioner. Basically it will allow you to log in to a remote revo site, from the local manager and view its resources, elements, files, packages, users etc. ultimately allowing these to be selected and imported into the local installation. The screen shots show the concept better. ’admin’ is the login screen, ’resources’ being the resource tree of the remote site.

Note, this is real code, not a mock up, the code so far is in provisioner.zip(this builds and installs on my windows box at the mo but all other bets are off here).

The drag/drop between the remote and local trees does work visually but of course not really as the dropped resource only exists remotely. Maybe put a dropdown menu on the tree nodes called ’import’ or something.

A basic workflow would be to first get a list of remote packages and install them locally, then users, then resources, then files, local chunks, tv’s etc.

I’m not sure yet if I can get all the data I need here through the connectors, also I’m not sure how far we go, do we need namespaces, contexts, policies or is it better to just limit this to resources/elements/files say.

All from here :-

http://bitez.hobby-site.com/index.php?id=63&relPath=projects/revolution/components

Please bear with my site, its shaky at the mo due to a refurb at home, its on a wireless connection, not wired so it can be painfully slow sometimes.

Interesting concept...Thx for sharing..

cheers/k

That is pretty cool. So you could manage all your clients directly from your own manager. Interesting

Very interesting. Will be neat to see how this progresses.

That is pretty cool. So you could manage all your clients directly from your own manager. Interesting

Nearly but not quite dev_cw, at the mo I only envisage reading from the remote site into the local one, not writing to it , however this of course will be possible.

Wow what a fun project shambett! I look forward to playing with it.
I’m guessing that if this is something that gains traction, then you will have people wanting namespaces, contexts etc as you suggest.
But there are a lot of worms in these cans, yah? As much as my imagination goes wild with the general idea you’re working on, I’d be just as happy to see you lock down the scope of Provisioner especially in terms of "what it’s for" or else it could get really complex really fast if you try to make it all things to all people (not suggesting that you are!). Maybe best to keep it simple, get it solid narrowly scoped, then gradually increase depending on where the interest lies (also making it easier to deal with the potential flood of "can you make it do x for me" requests). That’s just my $0.02.
Brilliant initiative.

This looks very very very interesting.

Looking forward to see where it goes.

Very cool. Remember that packages can interact with the user during installation and perform various steps like creating auxilliary chunks, snippets, system settings, etc. That would be lost if importing something other than a package. Some directly imported snippets wouldn’t work without the stuff that goes on during package installation (e.g. SPForm).

Yes, the complexities could be quite interesting here. I think initially its best to limit the scope as suggested by netprophet. With packages for instance I could supply a list of packages that the local user should install to bring the two sites together, but let him do this, a sort of ’diff’ list if you like. I think the best thing to do here is to try and implement my initial thoughts, release it then see where it goes after that.

Science fiction!