Jump to content

AlfPT - Alfred Package Tools (Workflow Installer/Updater)


Recommended Posts

I actually create a new website for workflows. it will be online this week end.

That's great! But I think you should team up with robhor to ensure that his workflows will work with your solution! And you should even inform Andrew to get the official support going!?

Link to comment

Hey chaps,

 

I thought I'd quickly chime in briefly about a repositories / package tools, why Alfred hasn't created one [yet] and what you can expect if you create something for this purpose.

 

Fundamentally, workflows can do anything, including potentially naughty things. Alfred provides the platform for these wonderful workflows, but due to the higher level of trust a non-experienced or non-technical user would have when browsing workflows originating from us, we can only currently provide a 'curated' stream of workflows (as per v1 extensions). Basically, the ones we promote are ones we are able to test and thoroughly trust.

 

I have some ideas to address this situation in the future (similar to Apple's Gatekeeper certificates), but for now, Alfred isn't going to host an 'official repository'. This isn't to say we won't create, maintain and foot the cost for a reliable unofficial workflow repository (or appcasting style auto updating system) at some point though.

 

If you are creating your own repos such as AlfPT, that's great! It's good to spread the bandwidth and server load, and also provide different or advanced features for the various repositories cropping up. However, it's worth noting that Alfred has a significant number of users (v2 will have even more so), so if you create a repository, expect huge peaks of bandwidth and server load around release times and when popular workflows get updated. Alfred can't help users with the cost of bandwidth as this opens the floodgates for others wanting the same.

 

Cheers,

Andrew

Link to comment

What about using a Github public repository like other package managers do (bower, npm, etc)?

Simple, free and safe. Developers will have to push their workflows on their own Github repositories (a lot of workflows are already on Github anyway) and do a pull request to be added in the (un-)official repository after getting approved by a list of maintainers (let's say Andrew, David, ...).

The workflow installer tools will be able to query the list of packages directly on Github without worrying about bandwidth or uptime

Link to comment

What about using a Github public repository like other package managers do (bower, npm, etc)?

Simple, free and safe. Developers will have to push their workflows on their own Github repositories (a lot of workflows are already on Github anyway) and do a pull request to be added in the (un-)official repository after getting approved by a list of maintainers (let's say Andrew, David, ...).

The workflow installer tools will be able to query the list of packages directly on Github without worrying about bandwidth or uptime

 

It would have to maintain a master list of all available workflows in GitHub as well. 

 

To expand on Andrew's post a little.. I have built several things that, I had high hopes for, thought you guys would love, only to see it fail because of traffic. The original Wolfram Alpha extension is a good example. When Andrew says, "when you create a repo, expect huge peaks in bandwidth and server load [..]", he's not lying. Tom's repo was a great idea, but it's going to be hard to maintain something like that. It's not so much the bandwidth because there won't be excessive bandwidth, but a LOT of traffic. Consider the fact that, Tom's repo was slow and eventually died with the small subset of users that have Alfred 2 beta now. Imagine what it's going to be like when everyone else gets Alfred. The standard, shared hosting plans that most individuals would have subscriptions to more than likely aren't going to hold up. Even the better ones like MediaTemple, you'll run over your quota of.. GPUs easily. 

 

Another great example, I ran a small site called GtWthr a while back. GtWthr provided weather data to users, as text, for a specified location. I used it primarily for showing weather data on my desktop with GeekTool. There was very little bandwidth because it was just returning a text string, but generating several hundred thousand hits a day... I couldn't keep it running. I paid $80 in CPU overages to MediaTemple one month :) I had fewer users on GtWthr than what we have beta members here right now. So just imagine how busy this is going to be when Alfred 2 releases and all those users are hitting a repo, searching, at every typed character.

 

Sorry for rambling but, I'm just trying to make the point that.. from experience, trust me when I say we can't just throw a repo up and expect it to survive. It has to be well thought out and planned, optimized to make the absolute best use of bandwidth and minimize the amount of traffic the server takes. Otherwise... Alfred Repo Fail Whale.

Link to comment

It also probably wouldn't be that hard to build a web site to browse the extensions once they're on github. If we standardize certain files that could be fed into the website, then it could just periodically query the main github repo to look for updates, pull the descriptor files, and update its own content.

 

Since it would be periodic, then everything could be cached fairly easily, and it would be much easier for users to find the sorts of workflows that they want. If varnish is running in front of whatever system is working with github, and cloudflare is running in front of that, then it should be easy(ish) on the bandwidth for users to browse.

 

That would also have the added benefit that developers of the workflows would control their content, so everyone, basically, maintains the site.

 

So, I like the idea of github as the repo. The Alfred workflows that interface with the repo wouldn't have to send people to the github site (which turns off many non-developers), and then there is a nice showcase for people who want to look for them.

 

Any critiques to the idea? Any suggestions on data structures?

 

Shawn

Link to comment

It also probably wouldn't be that hard to build a web site to browse the extensions once they're on github. If we standardize certain files that could be fed into the website, then it could just periodically query the main github repo to look for updates, pull the descriptor files, and update its own content.

 

Since it would be periodic, then everything could be cached fairly easily, and it would be much easier for users to find the sorts of workflows that they want. If varnish is running in front of whatever system is working with github, and cloudflare is running in front of that, then it should be easy(ish) on the bandwidth for users to browse.

 

That would also have the added benefit that developers of the workflows would control their content, so everyone, basically, maintains the site.

 

So, I like the idea of github as the repo. The Alfred workflows that interface with the repo wouldn't have to send people to the github site (which turns off many non-developers), and then there is a nice showcase for people who want to look for them.

 

Any critiques to the idea? Any suggestions on data structures?

 

Shawn

 

GitHub does indeed sound like a good idea—and, notably, this is pretty much how Sublime's package repository is handled—but for the problem of updating the master workflow list. It's easy enough to have people fork it and send a pull request, but we'd still need a reliable administrator or group of administrators to see those, check the formatting in the data file, and pull the new repository within a reasonable amount of time. The Sublime team—bless their overburdened hearts—tends to let a frustrating and arbitrary lag slip in, so it's never sure whether your package will be available in a day or a month. Again, I'm happy to volunteer my services—and I'll even take a look at the Sublime Package Control innards to see if there's anything useful there—but I think it'd take a fair-sized team to make this work.

Link to comment

All great points made here and I'm also glad that Andrew got in the conversation to let us know that when an official list goes up, in whatever form it may be, it will be censored. Not to say that in a bad way, it is completely necessary and understandable from their perspective and If I were them I would do the same.

 

However, for the rest of us, if we want access to workflows that anyone and everyone is willing to share, and then filter and inspect the content/usefulness of workflows ourselves, we will need a community style system. I think Alfred has enough users that once a basic framework is setup and people can contribute their time and/or talents to maintaining it we won't have any problems. Yes bandwidth is a major concern, but that is why sites like Github are so valuable.

 

If Github can power homebrew, I think it can power an Alfred workflow repository, just as people stepped up to maintain and even develop Homebrew the same will happen for whatever system gets setup to manage Alfred workflows. It's all a matter of time, once an individual with foresight steps forward and lays out the basic framework, there will be plenty of good minds willing to volunteer their time supporting a project they believe in... right now we just need a chief willing to forge the way as I think we can all agree this is an idea most Alfred users and workflow developers will get behind.

 

I'll be honest and say that person is not me. I do not have the required coding knowledge to anticipate and resolve the sort of obstacles a Github based workflow repository will generate. If it comes to dedicating my time to help test, or do tedious no-code related work I will happily give my time.

 

All in all, I am glad to see this discussion taking place with good people offering good ideas. Luckily this forum exists and the Alfred team is not censoring any cooperation amongst it's users so let's take advantage of what we've been given and for the time being remember that there will be a slew of more volunteers willing to dedicate whatever they can when they are given access to Alfred 2.

Progressive Downloader Integration Plug-in
Progressive Downloader Integration Plug-in
Link to comment
Sorry for my language, I am french.

 

The repository + workflow to handle it is near finish. The logic look like npm for node.

 

No register is required to push a new workflow or theme, just add a specific json file to your github repo, complete the form on the website with the github url and it's done.

 

I named it APM for Alfred Package Manager. APM handle themes too. I need 2 or 3 persons for testing, if you have already made workflows or theme it's better for tests. Thanks in advance :)

 

I have dedicated servers so the load is not a problem
Link to comment

Just a few more thoughts:

 

It seems like it should be necessary to have a compatibility specification. This idea was prompted from the Caffeine Toggle thread when the command "caffeinate" came up that basically does the same thing as Caffeine but is native to OS X. Well, it's native to 10.8 and doesn't exist before 10.8, so it should be made known in any place that can be browsed that it won't work with anything earlier.

 

Also, it might also be helpful to have as a requirement for listing the applications on which the workflows is based as well as a link to the app (maybe two different ones: one for the App Store and another for the developer's website, one of which would be necessary to have filled in just in case the app isn't in the app store or there isn't a developer site). I can easily imagine the scenario in which someone downloads the workflow for an app they don't have and are frustrated with the fact that the workflow doesn't work. I can also imagine the scenario in which someone is browsing the repository and doesn't know about an app and wants to learn more about it in a sort of way that browsing the workflows would lead to app discovery.

 

It might be good to have a readme file included with each (maybe?) that could, optionally, be launched at first run. That might be able to have a nice disclaimer: "This may break your computer, probably not, but, if it happens to do so, it's not the developer's fault." Some sort of disclaimer might be good to have on the website as well.

 

I have one reservation about having it so anyone can add a workflow via a github repository — what if they add things that aren't Alfred2 workflows? Or what if they add one that has a malicious script in it that can easily install some malware? With the Alfred2 workflows, it seems that it might be easy to do such a thing. I don't have a great idea on how to control for this right now, but it seems like it should be controled.

 

Also, is it just GitHub? I don't think that doing so is necessarily a bad thing, and I understand that having a a source outside of GitHub would require much more coding for the website, but there should be some pretty good documentation (or at least pointing to a documentation) on the website for those who develop workflows but aren't familiar with GitHub.

 

Thanks for putting more of this stuff together. It's pretty awesome.

Link to comment
@rice.shawn : Good idea for application compatibility, I will think about it.

 

I will put a disclaimer which must be accepted before downloading APM for Alfred. I will try to filter workflows but it will be a lot of work i think.

 

When you write the github URL of the workflow/theme, the website try to read a specific json file which is needed to continue. The repository is parsed to get name, author, icon, and the json file contain the version to determinate when it require an update.

 

The only constraint to use github, it's that developpers and users of APM must install git, it's a requirement to maintain workflow and theme up to date. And one repository for one theme or one workflow.

 

@rice.shawn : Why not put help to new user for pushing on github, but really, my english isn't so good to write it !

 

People who want test it, or help me to write a little documentation, just send me your email address by private message. I just need to verify everything is ok, so i can make it open for everyone
Link to comment
The only constraint to use github, it's that developpers and users of APM must install git, it's a requirement to maintain workflow and theme up to date

 

Forcing APM users to install git sounds like a bad idea, why not just fetching out the ZIP bundle (then unzip and replace the existing dir content) from the workflow repository on Github ? (Just append /archive/master.zip to the repository url ie, https://github.com/twitter/bootstrap/archive/master.zip)

Link to comment

@loris — Good idea on the not needing to install git. Also, it might be easier to just keep the downloadable file as just the workflow file instead of a zip so that you don't clutter the downloads folder with .zips. Since the workflow files are usually pretty small, zipping isn't too necessary.

 

@lazay — When I get some extra time, I'll write up a bit of documentation and post it here so that others can add/edit/remove before it goes on the site.

 

It might also be great to list an alfred install command for the repository that would download the workflow directly to the alfred workflow folder so that users don't even need to move/clean the workflow files from the download folder. So, in the listing of the workflow in the repository there would just be a line that would read: "to install through the Alfred Package Manager, just type "apm install '<insert package name for each listing>' into Alfred if you have installed the Alfred Package Manager." Then just make sure that the last "Alfred Package Manager" is a link to the apm workflow extension's entry.

Link to comment

It might also be great to list an alfred install command for the repository that would download the workflow directly to the alfred workflow folder so that users don't even need to move/clean the workflow files from the download folder. So, in the listing of the workflow in the repository there would just be a line that would read: "to install through the Alfred Package Manager, just type "apm install '<insert package name for each listing>' into Alfred if you have installed the Alfred Package Manager." Then just make sure that the last "Alfred Package Manager" is a link to the apm workflow extension's entry.

 

I would advise against this. I know it makes it more seamless but Andrew and I have discussed this in the past and it really should be left as a .alfredworkflow and the workflow that is doing the work doing an 'open' on the file so that they are prompted with the popup and can see exactly what it is (in more detail) that they are installing. Also, there is no sense in zipping up the .alfredworkflow files. A .alfredworkflow file is small because it is a .zip file with the extension changed. So zipping them is pointless, they are already zipped.

Link to comment

Why's that?

 

Creating a workflow and/or site for this requires a lot of planning and distribution of bandwidth and resources. The nature of the new workflows, sending a new request at every character creates a LOT of traffic. It makes it really hard to keep up with. There is another user working to create something similar. Let's wait and see what he comes up with

Link to comment

Creating a workflow and/or site for this requires a lot of planning and distribution of bandwidth and resources. The nature of the new workflows, sending a new request at every character creates a LOT of traffic. It makes it really hard to keep up with. There is another user working to create something similar. Let's wait and see what he comes up with

Ok. Thanks for the reply. I'll keep my head up for something like this.

A source for getting workflows and updating them could be really handy for Alfred 2, as workflows are such a powerful tool.

 

P.S

Now that I come to think about it, isn't this something that should be integrated into Alfred 2 itself maybe? I'm sure Andrew & Vero could pull something like this off, and make it as great as Alfred itself is. They already have the infrastructure after all, and other than 'by the users, for the users', or a censorship issue, I don't really see why this shouldn't be a part of Alfred itself (it'll be like a mini-app store, but for Alfred workflows).

Link to comment

As andrew explained earlier on this thread (i think). The main reason behind this decision is that they would have a really hard time making sure that no workflow will behave in a harmful way (or will purely contain a malware). 

 

Though, he is working on something.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...