[Suggest] Primo-Shell for VDF/VDD

[CrypEd]

(opened op new thread because other suggest was specificly about BATCHES)

Here is the idea that may be achievable:

Primo RAMDIsk could provide a hand-full customizable re-name-able "Settings-Template-Slots" for at least the RAM-Disk-Setting of Primo RAMDIsk itself, that the user can "tune" for using them with a new "small-scale" Primo-Shell on "images.vdf"-Files in accordance with the descriptor-VDD-files.

Example templates:
1. Name: Gaming. DIO, NTFS, no compression, no index, load only, no delay, letter R
2. Name: blabla. SCSI, FAT32, compression, indexing, load/save on shutdown, no delay, letter S
3. Name: blabla. DIO, NTFS, no compression, indexing, load/save, delay, letter T.

These are just examples, please do not answer with pros cons of the settings in the examples, i just made them up

Now what you do with these templates is that you right click on your *.vdf-File, move mouse over "Load with Promo-Shell" and then select the appropriate template you want to load the image using the template-settings!

This would be marvellous, reducing my average time spend in the Primo-GUI drastically, because basically I only mainly use one and same type for games only, the other 2 Ram-Disks for Programs are fixed load-only and no not need any change at all. Doing it manually causes my now in a "routine" to do the task in <10 seconds..... but still it could be <1 with those templates.

Now when R is already loaded with an image... this "PrimoShell" should automatically unload old image.... for that case the template could also define "volatile-yes/no" and if no, then save loaded-image to disk first before uloading it and loading a new one.

It is pretty much "like" the how Daemon Tools handles it, where you "pre-define" unloaded different devices and then simply throw in your image with one click into these predefined-devices.

This is much easier to work with!

By that ROMEX also can provide us, especially new-user, some "recommended" templates with names hinting the specific task, the settings will be useful for. . . so these templates may also be available for creating the image at first, at all.

Such "Primo-Shell" and such customizable "Device-Templates" for the VDFs could be a very very powerful tool to make Primo lot more "hand-some" to work with. Primo already features the VDD-Descriptor files.... so this idea should be pretty easy to achieve from the coding perspective. Just progrmming the "PrimoShell" to load the VDF-image bound to specific VDDs (incl drive-letter) and a programming config-page in the PrimoGUI to customize the templates-slot for the user to activate/deactivate and rename slots and specify previously exported VDDs for the slots would be enough.

It is also possible to exlude the drive-letter in the shell, which gives us additional quick and easy custumisability... so we would need a new template-format. Transferring a descriptor into a template is pretty easy, just remove "drive-letter" xD. Then you mouse-over "Load with Primo Shell" > "Device Letter List" > "Template List". Also these "Primo-Shell" should handle VDD-files, too, so when you right click a VDD-File, then mouse-over "Load Template Slot" > "Template-Slot-List", and selecting a Slot, this loads the descriptor into the template with the slot named after the descriptor file name.... that would be awesome, too.

From that moment on, only barely need to enter the GUI at all, basically few times after fresh install of Primo or when you need to manually save an image.... after that you manage loading directly from from your image-folder with Primo-Shell with your templates.
Also it could simply allow you, with a sub-menu to unload other images at that moment, so you really barely need the gui and wizards from now on.


Primo-Shell for VDF/VDD, what do you think?

BTW: Primo-Shell (Extension) may be advanced for handling "PrimoCache"-Image-files in certain ways later, too.

This would round up the product, primo-ramdisk and primo-cache with primo-shell for quick and easy maintenance in a nutshell of both of them. Damn, this said to be the shiznit?

[Support]

Many thanks!

[CrypEd]

Pictures say more than thousand words, so here's the visualisation:



Sry, just paint, no comment on art-skills please

It's not that i don't like the GUI or the wizards... these are great, don't get me wrong. But sometimes i wish it to go faster off the hand.

... please also note: RAMDIsk-devices should also need an "SHell-Extension" to simply unload or to manually save image...like in the GUI, sicne there is no Agent/systray.

It would be easy to visualise, but i think you can imagine what i mean.

Load: shell integration for VDF-template loading into specific device (see above)
Unload: simple shell integration for the devices to just unload
Save: simple shell integration for the device to invoke manual save
Config: simple shell integration to transit "VDD" into new or replacing "Template" (See above)

With these 4 function... you maintain nearly everything by your preconfigured templates in very efficient fast ways, without a GUI...without a systray-agent. . . .

Sure all that would need additional dll thats diggs into the system, but this is standardized by MS...so still make "these shell extension" optional on installation is wise decision i assume , since ya you might didn't now what restricted environment primo might be considered for or people don't want it, but is totally cool for "home-consumers" IMHO. Most application that use "shell extensions" allow to disable them at the custom-installation.

I hope you like the idea of a shell extension, thus handling only Primo-files (vdf,vdd,etc.) or PrimoDevices should be un-problematic, and impact is completely foreseeable and doesn't affect Primos inner algorythms. Still i don't think it would be a good idea to allow system-wide integration in the way to copy any data to the ramdisk by extension... like with the BATCH-idea, that one could be really problematic, so i opened up this thread.

Your welcome.

Let me know if consider planning such things like this, please. ^^

[CrypEd]

Just for completion:


All you now need is a explorer window for maintenance of Primo-RAM-Disks. . . it is easy and fast and safe.

That Primo-Shell for PrimoCache would look quite similar, thus it isn't really neccessary for cache, sicne we don'T add/remove caches that often... once their in place, you don't touch.

Anyhow:

Primo Shell functions for the Cache-block-device >> Flush to disk, Pause/Start, Stop
Primo Shell functions for the Cache configuration Files >> Start/Load that pre-defined Cache-task directly.

No templates need for cache..since Cache don't need "application" specific container..it is already meant for the hole device.. so no drive-letter seperation needed and the CFGs are already enough with the Primo-Shell.

But to not get the Primo-Shell handle any system-wide CFG you might consider a "new" file-extension for PrimoCache CFG... what about *.VCD (virtual cache descriptor)... handling any CFG is not a good idea considering stupid-users that may try loading non-primo-cfg do exist im sure... we need to protect them from themselves ^^

This would be also a nice explorer-integration, so we wouldn't need to start the GUI for such simple tasks.

[Laraul]

Why doesn't Primo use the VHD format? http://en.wikipedia.org/wiki/.vhd