I'm thinking about introducing platform-only apps for a couple categories and am looking for some thoughts. Please read the full post and then let me know any thoughts or suggestions you have.
The first category would be for apps where we can't legally distribute them. This would be something like CCleaner, whose EULA forbids even unaltered distribution of their portable version. Anyone even distributing the unaltered zip is violating copyright. If we went the ccPortable route and distributed an installer and launcher ala sPortable, that might work. But we likely couldn't use the logo or screenshots, also ala sPortable. And possibly not even the name. There are quite a few apps like this where we aren't allowed to use the name or app itself, but could handle downloading and having a portablization launcher for it.
The second category would be for apps that are already portable. These are mostly apps distributed as zips as a portable version from the publisher. The main advantage to having these is for updates via the platform anyway, so not distributing a standard bundled PAF versions outside the platform wouldn't make that much of a difference to users who don't use the platform.
The advantage to doing apps that are platform only would mean easier and faster releases for me. There wouldn't be news stories or app page updates for each release of them. Just a post within the platform's updater database. And, in most cases, I'd be divorcing the portablization package from the download of the app from the publisher, so nothing even needs to be released for new versions, just an update to the platform's database to separately point to the verified download of the portablization package and the verified download of the new zip from the publisher.
Looking for thoughts and suggestions around this.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Are you talking about non open source apps only?
My thoughts about second category: The main advantage to having these isn't for updates via the platform. It's the standardized format, which makes backups and upgrades easier. I don't use the platform very often and have never used the built-in updater (except for testing).
In my opinion we don't need news stories for each release (especially for apps with several releases per week/month), as long as we can find the download on Sourceforge.
as I undersatnd it, this would be apps only for users with the current version of platform.
I use platform, but version 1.6.
Updates are done manually.
By this I would not be able to use such apps I assume.
Ok, the legal things are complex, however for many apps it did work so far with the life installer. The portabilization package seems to be still needed, not exactly sure where what will better.
Otto Sykora
Basel, Switzerland
Out of curiosity, why are you using such an old version of the platform when newer versions have so much more functionality but still allow you to retain the old-school look of 1.6 if you want?
Sometimes, the impossible can become possible, if you're awesome!
will the new version work on w2k or w98se?
Otto Sykora
Basel, Switzerland
Windows 9x support is long gone and not coming back. Our compiler hasn't supported Windows 9x in nearly a decade. Our compiler dropped support for Windows 2000 soon after. We're still using a version from 2011 that happens to still work on Windows 2000 even though it's not supported. But we'll be upgrading in the near future and Windows 2000 will no longer work either.
It's also worth noting that nothing we release supports Windows 9x anymore. Our installer and launcher tech is Windows 2000 and up and has been for years as well.
Sometimes, the impossible can become possible, if you're awesome!
as I work still some time on machines with strange OS, eben w98se and have two with embeded NT4. Universal usb drivers on both...
but this is OT here
Otto Sykora
Basel, Switzerland
If I'm understanding correctly, and please correct me if I'm wrong, John, these applications would be made available only through the platform's existing updater, rather than made available on our website.
However, these applications, once installed, would be able to be used both from the platform as well as directly called, just like all our other applications.
Note that the availability of these applications would depend on having the most up-to-date version of the platform installed.
For the curious comments above on how this works and why it would save time, a default modified PA.c Launcher with all features enabled at compile time would be included with the platform by default. Say app XYZ is portable and releases regular versions on their site as XYZ_1.2.3.zip. Each new release I'd just be updating a single INI file for download by platform users with the new version and download link. The platform would take that and update the app structure. Compare that to now where I download XYZ_1.2.3.zip, unzip the contents into the app's folder, compile the PA.c Installer, upload the installer to SourceForge, wait 20+ minutes for it to mirror, update the app homepage on the site, update the updater database, create a news story.
Sometimes, the impossible can become possible, if you're awesome!
Provided these wouldn't be adding significant time costs to your already-full plate, I'm cautiously optimistic that this would be a net gain for us.
Category 1 - If I'm understanding correctly, these would be applications handled essentially as we do now, with the exception of not announcing or hosting a page for them, correct?
Category 2 - Dependent on the application, and more specifically where/how the settings are saved, these may still require individualized launchers. However, once the base package is built, there shouldn't be any need to change said package unless the base app changes settings handling itself.
I can think of a handful of applications in both categories that it might be beneficial to have available, even if they would be platform-exclusive.
[EDIT] Corrected spelling error in title of comment.
I really don't like the idea of any of our apps being tied exclusively to the Platform, as the 'platform agnosticism' of our apps has always been a big positive in my opinion: 'the PA.c Platform is great because of all these things, but you don't have to use it if you don't want to the PA.c Apps will work fine on their own'.
Also, Bart.S has a good point regarding the fact that PAF format apps have other advantages over 'portable' zip packages than just easy updates via the Platform.
I personally have chosen in the past to keep using an old version of the Platform for a while, so while I am up-to-date now, not being able to get an official PA.c app when I'm not using the most recent version of the Platform would be a big negative to me.
On another note, I don't necessarily always have my flash-drive on me, and might just need to download an app (CCleaner might fit this scenario) to use once on someone else's machine. I don't want to do a full install, I don't want to have to install the Platform in order to get it, and I generally stay away from self-published 'portable' zip distributions as I can't necessarily trust them to be fully Portable unless I've checked them myself.
For me personally, I see a PortableApps.com release as a badge showing that an app is truly "Portable", not just 'portable'. This is because many developers release 'portable' versions of their apps, but these versions often leave junk behind on the host machine, don't retain settings between PCs, almost never use relative paths or update their paths between PCs, and occasionally don't actually function correctly.
I do think that the apps that update particularly frequently don't necessarily need to have a news release about each one, just major ones (e.g. once per major version number, or if Chrome got switched over to PAL).
Anyway, I would think the use of an online installer would be fine, and again I don't think news stories are necessary for every build, but building the base version into the Platform download and not releasing a download for people who don't use the Platform seems like a bad idea to me.
I'd like to suggest an alternative to this proposal:
We could make a 'base' installer like you mentioned, and a 'stub' installer which downloads the base installer, and the 'portable' zip release, and the stub installer could be the published download. This would be somewhat similar to the 'stub' installers that Chrome & Firefox offer as their default downloads for local Windows installs.
~3D1T0R
The choice isn't between making them available as platform apps vs available as downloadable apps. It's between making them available as platform apps and not having them available. This is due to legality with some of the apps and due to resources with others.
They won't be available as an online installer because I'd still have to update those online installers for every single release. I am unable to do that. I do not have time. Updating an INI file based on a semi-automated process I can do.
Users who want a non-platform version are free to download the regular zip from the publisher's site. We may even post details and a link to it on the PA.c website. Users who want to download a one-time use version to delete when done and don't want to use the platform can download it from the publisher's site.
Sometimes, the impossible can become possible, if you're awesome!
If you're willing to publish them in a Platform-only way that you can effectively publish updates by simply editing an ini, I don't see what issue you would have with the 'stub' installer idea I mentioned. It would be effectively the same as your Platform-only solution, except that you would upload a 'stub' installer once, and publish a link for people who don't use the Platform that points to that 'stub'.
The 'stub' installer would do basically the same thing you're suggesting the Platform would do in your Platform-only solution, check the ini, download the 'base' installer and the current 'portable' release from the base app's publisher, and install appropriately.
Alternatively, it could include the 'base', similar to your design for the Platform's system (this could easily be implemented based on the current 'online' installers, but make it check for the current information about the 'portable' zip release from the Updater's db in order to know what to download.
If you're at all open to either of these ideas, but perhaps don't want to deal with the implementation details, then you could post a sample of how you'd put this information into 'an ini' (I've kind of been assuming you mean the Updater DB. Am I right?) and I can work on implementing either a 'stub' installer, or a sort of 'remotely versioned' online installer (my initial idea was the former, though I think I'm leaning more toward the latter now).
~3D1T0R
I won't do that. Because when I need to update the stub installer tech, I'd need to post updates for the stub installers for every single app. No way, no how. The whole point of doing it in the platform is to ensure that it's a single point that needs maintenance and updating. Not dozens or hundreds. Plus the fact that the stub installer doesn't address the whole reason I can't do many of these apps legally in the first place. I'm not going to create a bunch of apps with names like sPortable or ccPortable with no names or screenshots attached on the website.
Sometimes, the impossible can become possible, if you're awesome!
I've continued considering your comments as well as implementation details and here are my thoughts at the moment:
Even if I can convince you to go ahead with a 'stub' like solution, there's no need for individual pages if that's an issue. You'll want to have a page explaining these apps, so you can include a list of all of the apps that use this system on that page, with nothing more being necessary than the name of the app and a download link.
As for the issue of updating the technology behind the 'stub' installers, this could be minimised by having the Platform and stub both utilize the PA.c Template (which could be listed on the Updater DB so they can get the newest version if they don't have it) and have a download (potentially an ini) for each app, which defines the changes necessary to turn the Template into '{AppName}Portable'. This way you could update the Template and effectively update the PAF containers for all of them at once. This also keeps most of the logic out of the 'stub', so that any changes to how it works can be made by updating the ini file(s).
Also, the stub installer could be implemented so that it checks it's own name to see what app it's for (similar to how the 'online' installers check to make sure they say "online" in the name), meaning that you could make any changes to the stub by replacing a single file on the server and having each link define the name but actually download the same file. And the issue of having old versions of the 'stub' in the wild can be addressed by having the 'template mutation definitions' file contain a version number for what 'stub' is able to utilize it, then the stub can either have an error stating the user needs to 'download the new stub or switch to the Platform', or it could automatically download the new stub and replace itself.
Edit:
If there really is no way I can convince you to allow non-platform downloads of these apps, I'll have to throw my vote against having the apps available at all unless/until there are enough resources to publish them as properly PAF'd releases, because I don't think it's right to lock our users to the Platform.
If there's any chance you might be willing to release a stub-like downloader for them, then I'm tempted to say you should implement your Platform-based solution in the open where we can see it, and I (and hopefully others will help?) can make the stub based on how it works so we don't have Platform-locked apps like U3 & LiberKey.
Edit2:
I'm starting to wonder if maybe it would be better to try automating more of the work involved with the releasing of apps, and (in particular) updates. If there was a script in a git repo that could build the app, upload the files and push out the associated news stories, you or any Release Team member could update the script for a release and push it to the git repo, then the actual act of publishing the update could be as simple as running two commands "git pull" and "publish AppNamePortable" (or something like that). This would deal with category 2 very nicely, and could be used as a jumping-off point for category 1, in which the script would instead be designed to run on the end-user's computer, and the Platform (and/or stub if I can convince you) could download the script and run it, effectively building the app in place. Further, it would be able to streamline the update process for all the other apps that don't fit into these two categories too, meaning more time for you to work on things other than updating apps.
~3D1T0R
I'm 100% behind this method. My vote is to do as 3D1T0R is suggesting as it still leaves the Platform the best in my opinion. "Locking out the end-user" as he's saying is a terrible idea and is a huge step backward.
daemon.devin
It would still lead to a huge duplication of code amongst tons of stub installers of different versions all to accommodate an edge case. I'd basically have to write a mini-platform section and mini-updater in every stub installer for it to fully function. The stub installer would need to live download this additional platform stuff, the generic compiled PAL launcher, the app's detailed INI file, and then any files from the actual publisher (4 plus downloads as you install). It would then need to extract and assemble it all. The resulting file would have a AppNamePortable.exe that would have a generic icon and generic name that would not reflect the app, so if you're using it in a third party menu, it would show up with a PA.c icon and "Multi-Purpose PortableApps.com Launcher" as the title. All that when the user's other option is to just download ccleaner.zip from the publisher and point their menu to its main EXE.
Again, this is not designed to replace existing apps, it's designed to handle lots of already portable apps in an easy style to enable platform updates of them. The preference is for PAF-style apps. The main preference would be for the publisher to do them. Where they are unwilling or unable, we'd have a new method of delivering apps to users.
Building apps in place in terms of compilation is a bad idea as it will lead to tons of false positives, so it's a road I have no plans to go down. We had enough issues with false positives just using UPX to shrink apps for portable storage when that was the norm. Even now, live downloading via live installers causes lots of false positive issues. That's one big reason whey when you're updating your apps via the platform, every single download of everything (app database, PAF installer, EXE/ZIP from publisher) is handled via a single digitally-signed EXE. It drastically cuts down on issues.
Sometimes, the impossible can become possible, if you're awesome!
Here are my thoughts on the topic at hand:
Just go with what you think is best John, especially if it makes it easier and less time consuming for you.
There is no reason why users can't simply just have the platform installed somewhere and use it to keep apps up-to-date, and then export the apps from there to whatever launch method they use for the setup that they prefer.
Maybe even add a simple feature to the platform that does this exporting interactively (via the context menu).
Sure, there will be times when the installs via the updater won't work for whatever reason, but that could easily be mitigated by having a webpage that lists all the downloads that can only be gotten via the updater (or even just all the available downloads), and have users download the ones that failed manually via this webpage that could be auto-generated from the app database.
These manual downloads could then be put into a special folder that is used specifically for successfully continuing these failed installs.
An ideal solution would be to have metafiles (whether in a simple ini format or a specialised format) in this folder of the installs that failed, so that the platform/updater can tell what it is supposed to do with the packages in this special folder. This process would only start the install continuation if all required files have been downloaded and placed into this folder (as specified per metafile).
I don't think anyone wants to make a system for exporting apps from the Platform to other systems. Besides, even if people don't use the Platform, people generally use the same basic "X:\PortableApps\AppNamePortable" structure (admittedly some choose other names than "PortableApps" for that directory's name, but I think that's pretty much inconsequential here), so someone who wanted to use the Platform for updates, but something else for actually launching their apps, wouldn't need to 'export' anything.
Also your example of people having download issues through the updater makes the idea of a 'stub'-like installer for these kinds of apps an even more attractive idea, as one could potentially download the publisher's 'portable' release, put it next to the 'stub' (similar to current online installers) and although the stub would still have to have internet access (to find out what it's supposed to do with what) it could help people who have difficulty with unreliable internet.
~3D1T0R
Yeah, the export part of my comment can just be ignored. It would be rather time consuming to actually put together properly anyway, and isn't really needed.
As for the stub, given that it would be built with the same components as what the updater is currently built with, it would face the same issues as the updater with downloads. The issue could be with downloading the apps, or it could even happen to be the app database that can not be reached properly. Unreliable internet gets in the way of both cases (as it is by it's very nature, unreliable), though it is usually the downloading of apps instead of retrieving the app database. If the stub could use a copy of the database that has been put next to it, as well as the publisher's 'portable' release, the stub wouldn't even need access to the internet.
There is a better way though, my idea of which is adding a downloads cache to the updater which can have app releases manually downloaded to while the updater waits to find the files that it would be expecting to of downloaded.
Though this would still require the use of the platform, even if it is only used for the updating of apps.
If the issue is with PA.c being blocked, then neither the updater or stub would work, as they couldn't get the db, but "unreliable" internet, is less likely to effect downloads of the db and/or scripts, as these are fairly small downloads compared to the apps themselves. Having the 'stub' use a copy of the db manually downloaded next to it completely defeats the purpose of it.
The best thing for people with unreliable internet would be to switch the updater (and online installers) to a different system which allows for download resuming. I have ideas for this, but that's a discussion for another time.
My issue with Platform-only apps, is exactly that: that people have to have the platform, even if they don't have to use it to start the app. People should be able to choose to, or not to, get the Platform.
~3D1T0R
There would be no duplication of code between stub installers, as there would only be one stub installer, which checks what it's name is to see what app it's for, and several links which download it with the different names so it can work for different apps.
I don't get what you mean by a 'mini-platform section', and as far as a 'mini-updater', ... that's basically all the 'stub' would be: A downloader. The actual logic would be in the script that it downloads.
And again, I don't get what you mean when you refer to 'additional platform stuff', but I was thinking of three downloads, not '4+': The PA.c Template, a 'template mutation' script, and the 'portable' release. There would be no need for compiling on the end-user's machine, as everything needed would be included in either the template, the script, or the 'portable' release. When I said "building the app in place", I meant only that it would place the files from the downloads where they need to be to make it into the finished product.
And my whole "Edit2" isn't about the "Platform-only Apps" idea, or the "stub-installer" idea at all, but an entirely separate comment stating that if you're running low enough on time because of the process of actually publishing the apps and their updates, I think we could improve that process, so that that part of running PA.c takes up less of your time for any and all apps.
Anyway, my basic issue with the idea of Platform-only Apps boils down to this:
I CANNOT recommend people to go to the base app's publisher's website to download a 'portable' version of an app, because I can't be sure it's really Portable unless I've checked it myself, and if I recommend it for one app, they'll think all such 'portable' versions are OK. Instead, I recommend people to go to PortableApps.com for Portable Apps.
If I recommend PortableApps.com to someone, they should be able to go to PortableApps.com, and download whatever app(s) they want, not be required to download the Platform, in order to get the app they want.
That's not to say that I don't recommend the Platform to people too, but if they don't want it, they should still be able to get whichever app(s) they want from the website.
~3D1T0R
I'm looking for a low-impact way to make platform users able to update more apps. Heck, I may not even put them in PA.c Format. I may have it disabled by default but available for end users with the caveat that they may not be fully portable and may leave stuff behind and may have all sorts of other issues with a big warning to that effect when they enable it. These won't be full-blown PAF apps.
You're still free to recommend real PAF apps from PA.c where they're available. The choice here is between making these other apps available at all and not. I will not be supporting these additional apps to the same level of standard PAF apps nor recommending or supporting their use outside of the platform. I won't take on that time commitment or support cost. And most of them would be illegal to distribute on their own unless I name them something dumb, again, back to the example of CCleaner and sPortable.
I might consider making the script available with a basic launcher that advanced users can download, rename, and then manually insert the files from the publisher if they choose with the understanding that it's unsupported. They'd have to assemble and update it themselves and wouldn't be supported by us or the publisher. Or they can use the platform to assemble and update them.
Or we could consider releasing it as a secondary commercial product outside of the platform if there's enough interest so I could afford to support this additional effort and maintenance. That could be one way to do it. Make it a paid add-on to have these extra apps available and as we hopefully get more publisher interest, get them to release legit PAF versions for free and move them to the platform proper as well as solo downloads.
Sometimes, the impossible can become possible, if you're awesome!
If you're not planning to put them in PAF format, and just want to make updating of the publisher's release possible, I do think they need to be vetted to make sure they're "stealth" (as PortableFreeware calls it) before they get added to the list, and I'd suggest publishing this as a separate 'non-PAF portable-app updater' app (or Platform add-on, not included by default), which would have a separate Updater DB, and not bother doing anything other than downloading the publisher's 'portable' release and installing (if it has an installer) or extracting (if it doesn't) it to where this updater and the Platform can find it. This seems more in line with what I think you were originally going for, and would mean we're not releasing these apps, so the "don't tie Portable Apps to the Platform" stance doesn't quite apply the same.
Note: I don't think building this functionality into the Platform's existing Updater would be a good idea. I feel the built-in PortableApps.com Updater should be reserved for True PortableApps.com Portable Apps, which following the PA.c Format.
If you go for calling it a 'Platform Add-on', I wonder how you'd integrate it into the existing Platform? Add a second (Check for Updates to non-PA.c apps) menu entry? or have the existing PA.c Updater launch it (if present) when it's finished installing Updates for PAF apps?
As for monetizing it... what are your thoughts on how to actually implement that?
(I'm imagining users getting a 'donator' status on PA.c, and the add-on requiring your username & password to see if you have it)
Not sure if I like that or not...
Another thought: Something similar could be achieved by adopting/forking AppUpdater. (see also SourceForge)
~3D1T0R
Building this functionality into the Platform's existing Updater would be quicker to implement as it would involve adding a single option to the "App Directory settings" area of the Platforms Advanced Options (or even just a new entry in the .ini) and then adding the code to the updater to handle this new setting.
The skeleton of this new functionality could be based off of the "Show Advanced Apps" setting's code and be toggled off by default.
And for users who don't want to use the Platform, they don't have too. They would be able to download manually, but they would have to put the finishing touches on the apps themselves (as per what John said).
While adopting/forking AppUpdater would be a good idea (apparently AppUpdater is even PAF'd itself, though v2.3 portable is no longer supported), the amount of work involved in modifying it does defeat the purpose of this discussion.
Given the amount of work required, if adopted/forked, it would be better for the modified AppUpdater to eventually replace the existing Updater.
>I'm looking for a low-impact way to make platform users able to update more apps. Heck, I may not even put them in PA.c Format. I may have it disabled by default but available for end users with the caveat that they may not be fully portable and may leave stuff behind and may have all sorts of other issues with a big warning to that effect when they enable it. These won't be full-blown PAF apps.<
well but this is then kind of end of portable apps completely, I think to give up all the idea behind it and simply work toward quantity instead of quality is not the best. my opinion simply.
Otto Sykora
Basel, Switzerland
It's more of a middle-ground between quantity and quality. The idea is (as I understand it) that by adding this basic support for non-PAF apps, users could get these extra apps that aren't normally available in a truely platform-compatible package, without doing the extra work needed to set them up properly. All while the PA.c team tries to get the actual app publishers to release a PAF version of their app.
user can get any incompatible apps themselves and place them even into the platform. Then they have the same result, mix of portable and 'maybe bat not tested portable' software. Same way as today. But the idea of portable apps remains clean and clear. Still do not undesrtand why it should be needed to fill the platform with many incompatible and non portable apps just to satisfy users who anyway do not care if the app is portable or not. The number of junk apps will be certainly soon much bigger then seriously portabilized apps. Users who do not care if an app leaves all data behind or fills registry with junk will be certainly happy. But should this be the target user group really?
It means simply spoiling the reputation of poratbleapps as quality product.
Otto Sykora
Basel, Switzerland
Any plans to switch currently available open source apps to platform only apps?
There are several projects which release their own app.zip and have no interest in building an app.paf.exe themself.
The goal would be to have standard PAF apps as time and legality permits. Ideally, it would be to have publishers adopt PAF and post their own packages like HWiNFO, Task Coach, and many others do. I'm still considering ways to have proper PAFs be more prominent than the platform-only apps in the platform itself as well. The goal being to make publishers want to do them. I may make it so commercial apps are PAF-only, for instance.
Sometimes, the impossible can become possible, if you're awesome!
If it can improve our list of offered apps with minimal additional ongoing workload on you, John, especially apps we otherwise couldn't offer (but some of which are quite often requested) then I say go for it.
That said, for the sake of full disclosure, I also only use and install apps via the Platform anyway.
If it reduces the workload, and allows apps to be updated frequently in a timely fashion then go for it!
Hi Guys,
As a user of PortableApps (I really think this is the only thing keeping me on Windows) I really like this discussion.
With your permission, few remarks from a user point of view.
First, the most important question - Why do we use PortableApps Applications?
1. No need for privileges rights.
2. Doesn't deteriorate the OS performance over time (You need to make this more known to the public users!).
3. Application are virus scanned and the source (PortableApps) is trust worthy.
4. Applications are auto updated.
Once you keep all those in tact, as user what I'd like to see:
1. More applications (Namely, since currently the resources to support applications are limiting the additions of new applications, we need a more salable solution).
2. 64 Bit only installers
Many of us use 64 Bit only OS's we don't appreciate those 32 + 64 Bit installers. Keep them apart and let the user select "64 Bit Mode".
3. Automation form Portable Zip
If a publisher has a verified portable version of its program (No registry or left behind files) make the creation of PAC installer automated which means being able to publish those takes almost zero effort.
4. Share Data to Choose Which Program Is Next
Give the users ability to chose the next new program in the suite from candidates. Too many programs are in endless beta phase. For instant, mwayne has many programs he keeps updating them. Why not add them?
5. Sync Profile
I have a set of installation on one computer. I'd like to create the same set on a different computer. Could we share a configuration file which automatically makes the suite downloads a list of applications?
PortableApps is amazing.
In my experience this is what keeps my system running like it is new each day (No over time performance deterioration).
I really think this key feature isn't used enough to bring new users which means more popularity, more donations and more collaborators.
Thank You.
all this will lead to situation where all sorts of junk, portable or not , will be able to install itself 'as portable app'
There is no controll any more.
While some people will get happy to have suddenly thousands of apps , other users will suffer as they have to have latest version of the platform allways installed. This can be sure understood as binding customers, but here this was allways said that nobody is forced to use the platform. Apps did work also alone.
There were competitors around, doing exactly what is discussed here, their apps were avaiable only with their platform. This was critisized by folks and now the same seems to be suddenly popular.
People use portableapps for their quality and not quantity.
Less apps with best functionality, best check on portability are definitely more value then thousands of junk apps of them no one knows how they really behave.
For me this sound all like giving up the idea of portable apps completely. Pitty. It was such a good idea.
Otto Sykora
Basel, Switzerland
I think you see it different than you should.
No one will remove the idea of PortableApps.
John is just looking for behind the scenes method to be able to scale the platform to more applications.
Currently the method of publishing application, or even only an update to application, takes too much time.
The discussion is how to make this process more efficient and scalable.
Portable applications will be kept portable, no registry, no user data in user folders, virus checked.
when we have here still few classic paf apps, but many apps which are just as portable as the publisher understands it, meaning 'so called portable' apps which in fact are not portable as we know, then they will just be mixed with the proper done once it means the end of portable apps policy to have tested and properly portabilized apps.
While the current really portabilized apps will certainly be available for some time, they will become just minority. Apps will be 'so called portable' just because the publisher produces a zip file, but does not care abt real portability.
I agree that it takes lot of time to maintan the apps, but why then not reduce the number of apps and keep quality, instead of increasing the number of apps with poor quality?
Reducing the number of quality apps would also reduce the time needed for maintenance.
OK, it might be welcome as many users do not care about the functionality, they do not care if they have finally lot of junk on their machines full of left overs. Probably more folks look for thousands of apps rather then 10 apps with proper quality.
It is going to be quantity before quality, portabilization left to imagination of any publishers.
This is what I mean the end of portable apps.
Platforms with similar functionality when apps were fixed to the platform were around for many years. They made nobody happy. This site here was mostly proud of being better then all the rest. Now it is going to the same direction.
Otto Sykora
Basel, Switzerland
Not entirely true there. I don't think that the publisher PAF release would get added to the app database if it didn't do things properly. And whoever ends up doing the quality check of the PAF release of the publisher PAF release would contact the publisher to let them know what should be fixed.
Again, not entirely true. The other platforms with similar functionality that you talk about use generic methods to make the app portable. From my personal experience, Ceedo was the best of these (in the days of Ceedo Personal) as it hooked into the app to redirect filesystem calls, registry access, and possibly others to the platform folders (now seems to require something to be installed on the system for the redirections to work though). User added apps were a problem as it required users to buy an addon to allow installing apps outside of the appstore.
Where as with PA.c Format apps, more reliable methods are used to make an app portable (which can be fine-tuned, and missing functionality can currently be added through custom code. Though custom code may get removed in the future afaik).
This won't change with what is being discussed in this node.
the idea seems to be to simply import the zip files as many publishers produce and add them to the platform without making them paf compatible.
This is the major point here. Publishers delivering paf apps by themselves are still very seldom.
Publishers generally produce some zip and call it portable.
This is the point here.
If platform had used at least ceedo in past, ok would be fine to some extend. But there were number of platforms around where the apps were available only via the platform and often it was just some kin of quick unzip and rename it for some format compatible with the platform only. Most of them did not survive as the functionality was not transparent at all, no support at all etc.
Otto Sykora
Basel, Switzerland
That's not the idea at all.
The way John wants to handle this won't be entirely non-paf.
In a previous comment in this discussion, he talked about a generic PAL Launcher with all features enabled that would use a detailed app specific ini that would make these non-paf apps truely portable, and for this generic PAL to be integrated with the platform to some extent.
They would only be install-able through the platform this way until the publisher decides to deliver their app as a paf app. At which point they would no longer be in this category, instead probably being moved to the paf category.
I vote for not making platform-only apps.
Making "non pa.c format" apps available would decrease quality and reputation of PortableApps.com. At the moment users can trust the apps available here. I think I wouldn't recommended PortableApps.com to friends any longer when you make platform-only apps.
If enough users request a paf app, publishers will do it or users will switch to a better app for their needs.
And I wouldn't do online installers, stub installers or other things like that at all. Only 1-file installers are good for backups (if you need to install an old app in the future).
In that case, for the purpose of a backup copy of the installer, after the app has been installed but before running the app, PortableApps.com Installer can be run against the apps folder to make a single file installer (after editing the installer.ini to remove the download section)
Sure, let the users create their installers and software on their own.
Make PortableApps.com redundant again.
I thought we were talking about installer backups for an old app that may no longer be available in the future, but, okay
But in all seriousness, if that was more common, and with high enough demand, the required functionality to be able to do this automatically after install would probably be added. (Except for PortableApps being made redundant... that should not ever be made to happen)
After considering all the discussion above, I'm no longer entirely against the idea, depending on how it's implemented, however I do think it's the wrong approach to the issue.
The reasons for the 'Platform-only apps' idea are two-fold, to allow users to update more apps while spending less time preparing them, and to allow updating of specific non-PortableApps.com apps which can not be legally released by PortableApps.com.
To deal with the first reason, I believe that by automating the building (and hopefully publishing) of PortableApps.com releases in PortableApps.com Format, we can get enough time back from the apps already released, and continually needing updates, to make proper PortableApps.com releases of more apps more feasible.
As to the second reason, I think non-PortableApps.com Format releases should not be embraced in such a fashion by PortableApps.com, as this would devalue proper PortableApps.com Format releases, removing one of the major reasons some of the base app's publishers give us permission to repackage their apps, meaning the likelihood of PortableApps.com gaining permission to release proper PAF packages of more apps goes down.
On the other hand, I can understand doing something similar to this for specific apps where the publisher(s) refuse to give us permission to repackage their apps, however I would lean more towards an automated 'build-your-own PortableApp' app for these, which could have a separate updater database in order to offer updates to the apps built with it, this would again offer proper PortableApps.com Format versions of the apps to our users, and also fall outside of the packaging restrictions as we're simply providing our users with a means to easily build the PAF package themselves, also it would be able to be 'updated by only changing an ini', just like your 'platform-only' solution, as it could include the PAF Template (and potentially update its copy of it too), and would know how to build each of the apps it supports, needing only to know where to get the most up-to-date version.
~3D1T0R
>where the publisher(s) refuse to give us permission to repackage their apps,<
who bothers abt apps where the publisher is not willing to cooperate? They should keep their apps and do what they like with it, we do not need their products.
Otto Sykora
Basel, Switzerland
There are some specific apps which many people WANT to have a PortableApps.com release of so that they can use the PA.c Backup system and keep it up-to-date with the rest of the PA.c suite, but PortableApps.com isn't legally allowed to release them. For example, Piriform's CCleaner. This is one of the reasons why John is contemplating a system 'Platform-only' app releases.
While on one level I agree with you that we should generally just leave such apps alone, on another level I think there are exceptions where there's enough demand for it, we're willing, and maintenance would be minimal (i.e. 'portable' releases which are actually portable). John's looking at the current system we have for such exceptions (online installers with names like "sPortable" for Skype) and finding it lacking, especially for programs where the app gets updated very frequently.
My suggestions are an attempt to find a sort-of 'middle-ground', where we can offer such apps if we deem it advantageous enough for our users, without losing what makes PortableApps.com so great.
~3D1T0R
I look at it other way around.
If someone really need things like CCleaner, he is free to get it from piriform and place where ever needed. Or he can use the already paf of wise cleaner here. Why to bother. The result is same, except platform might go and collect some updates from pirifom , but this can the ccleaner do too.
No need to serve publishers who are not cooperative. Let the users who can not live without such junk as CCleaner to resolve the problem with piriform themselves.
Otto Sykora
Basel, Switzerland
It's more about the users of PA.c than the publisher.
Meaning that the work done here to make these apps properly portable (without modifying the app) gets done because of the high demand for this app from users.
If the demand is low, then that work usually only gets done if someone feels like doing it and feels like providing maintenance for the app.
Actually, to my knowledge, CCleaner doesn't download its updates. The user has to goto piriform and manually download the update and then install it.
If that attitude was used by the PA.c team (which it is NOT I might add), users of PA.c would be driven away as they would feel like their freedom of choice was being removed from them.
Couldn't of said this part better myself.
> CCleaner doesn't download its updates<
it does
Otto Sykora
Basel, Switzerland
In a perfect world with many developers helping John the users would get any application they ask for and it is portable by policy of the original developer.
In practice, there are too little developers and John can't handle having so many applications while users want many more applications.
Possible solutions:
1. Get More Developers (Official).
This might be solved by more people with knowledge getting involved and by change of policy of official developers. For instance, how come all mwayne applications aren't published as official? He has supported them constantly, they are great applications, etc...
More developers sharing the burden -> More applications -> More users -> Greater spread of the project -> More Developers (Hopefully more donations as well).
2. Automate the PAF Creation Process / Making It More Efficient
With the same development resources handling more applications must mean spending less time on each. So either make the creation more efficient or solve it by using "Portable" application which won't require PAF compilation.
Those who oppose the last step must say how to deal with other issues.
Maybe better automation using Python?
For starter, why the official team doesn't add more people to help it carry the burden?
In the end, we need more applications and more users (Potential developers).
As the project gets bigger the motivation of more companies to officially support PAF will rise.