It appears this pull request is still pursuing the idea that the web services API returns in HTML format. I cannot stress enough that this is bad practice. It goes against the industry standard on any number of levels and it presents a layer of inflexibility that is not standard (in other words, the web site cannot override the styling as we can it every other place in the Joomla CMS).

Unless such a basic aspect of the design is factored, it's a -1 from me for merging. I don't want to trivialise the effort that has gone into this, but at some point you've got to call a spade a spade and this is simply not ready to include in the CMS. Apart from that, there is no word on when the server will be working and in projects like these, you have to include that as part of the offering. It is really concerning me that this is being pushed through when people with experience are offering their help and their advice is being ignored.

In addition, we also have a brief from the CLT for a complete JED rewrite which seems to overlap this effort considerably. Given the level of detail in that brief, I think it's premature for this project to be merging anything. This should be designed as a separate component that test sites can opt into. Only when it is battle hardened should it be included in the core.

Please note, this is not (and has clearly never been) intended to be (on well thought purposes) an API for developers and data-miners to the JED, sorry. This is not a web-service, it's been implemented as a Web-App.

It is just a cool and useful feature for users that is present in most CMSes nowadays, which results from a long design process by a large group of qualified web professionals. Additionally, The client has been designed to be compatible with the design of the new JED.

For the server part (which is a custom design that happens to have been open-sourced because that's the right way of doing software), there is an updated tracker item to collect feedbacks. This is the client part implementation.

So if I understand this code correct, you are first going to do a request to http://appscdn.extensions.joomla.org/webapps/jedapps/js/client.js?version=3.2.0 using ajax. The request will return some instructions which CSS files (atm two files) and JavaScript files (atm 3 files) to load and a JavaScript code to run. This returned JavaScript code will then do the ajax request (initially http://appscdn.extensions.joomla.org/webapps/index.php?format=json&option=com_apps&view=dashboard) which returns the HTML code (wrapped in JSON) to show.

My main question at the moment is: How will you make sure your server doesn't get hacked? Because if it is hacked, this may potentially open a security issue for all Joomla websites. If a hacker manages to change the initial script response (or one of the referenced files), it isn't only run on the server, but on each Joomla backend. The same will be true for the HTML response. I'm not a security expert, but this sounds a bit scary to me.

Please note, this is not (and has clearly never been) intended to be (on well thought purposes) an API for developers and data-miners to the JED, sorry. This is not a web-service, it's been implemented as a Web-App.

Just a note on this. Even if it's not intended, you already built (and have to) an API. Everyone can request the URLs. The only thing is that one needs to parse the returned HTML instead of directly using the data, which isn't very hard to do. The dashboard will list all categories. You can request a specific category using &view=category&id=1234 or an extension with &view=extension&id=1234. You can even filter and order in the request.
It is an API, just neither a good or safe one.

Some other questions:

• How long will you support old Joomla installations. Like when Joomla 3.2 or 3.5 respectively is end of support, will you still support it? Will you support it till JED drops the data (like recently with the J1.5 extensions)?
• What happens in the client if you drop support for a particular version? Will there be an error message explaining what is happening?
• How will you make sure that the client in old Joomla installations will still work when you adjust the output to newer versions? Will you test against each version and (probably) maintain different HTML and Javascript outputs for each version?

Speaking about KISS: You're aware that this would be much easier if you used structured JSON data and just process the data from the client? You could serve the exact same data format for each Joomla version without worrying about breaking anything. For newer versions, you could extend it with more informations without breaking anything for older installations.
It would also be easier to understand for developers looking at the code, as it would follow the normal MVC behaviour of Joomla.

Hi Beat. I understand where you are coming from but you misunderstand that my assessment still stands whether this is a user feature or a developer feature (the distinction is meaningless to me because the ideal design for me is identical). The response from the server should be structured data, not rendered HTML. If you want rendered HTML, create a view on the JED site and load it in an iFrame. This is not a new principle. It's been around a long time (cf SOAP, XML-RPC et al).

Respectfully, the client isn't designed to be compatible with the design of the new JED because they only just released the functional specification and nobody knows exactly what the final solution will look like (we can guess, but we don't know for sure). I'm not sure you know how this can be unless you have inside information which nobody else is aware of (in which case, whatever, just don't be surprised if people get frustrated when they don't get told the full story).

I'm not sure about what you mean by "which is a custom design that happens to have been open-sourced because that's the right way of doing software". Yes ... so?

Yes, this is the client. My assertion is that the client has been designed inject pre-rendered data in the output of the component and this presents a number of concerns:

1. The output cannot be adjusted by the client. For example, Hathor will not be able to fix any accessibility problems in the rendered output from the server.

2. The industry, whether open source or not, standard for this type of scenario is to pass around structured data, not rendered data. This is a long standing principle in the architectural design of these types of systems.

3. Preparing the client to receive structured JSON will allow for easier integration in the JED rewrite with minimal changes because I predict it will work with RESTful services out of the gate (and the specification makes some hints that this is a desirable outcome).

4. It would make far more sense to wait for the JED rewrite to at least accept a vendor so that we know what the engineering specifications are. Doing so will avoid "guessing wrong" about what services may or may not be available in the future.

5. This is being pushed through, in my opinion prematurely, to comply with the current development strategy (that is, no new features after 3.2, which can be bent anyway because I believe the version check feature is going to be back-ported into 2.5 anyway). This provides conditions whereby we are pressured to slap "something" into 3.2 regardless of whether it makes sense to or not. The correct course of action is to either wait another six months for 4.0, or change the rules for the 3.x series to give every a bit of breathing space. I would opt for the latter because I don't see anyone doing any work that justifies a major increment (again, just my opinion, but a related factor nonetheless).

To be clear, I don't really care how the client is designed, but the non-negotiable for me is that it must expect structured data. You may care to disagree but I hope that the PLT does not.

@Bakual you make some excellent points about versioning. It's very simple to support that using a RESTful service - not so easy if you stay with the current architecture. Not to mention what happens when you change the HTML response from the server and site builders have worked hacks into their template to override behaviours, etc.

1.The output cannot be adjusted by the client. For example, Hathor will not be able to fix any accessibility problems in the rendered output from the server.

@eddieajau In Hathor it actually doesn't work at all since jQuery isn't loaded. And even if it is, it probably will fail because there are no Bootstrap Tabs which could be expanded using JavaScript. So at least we don't have to worry about the accessibility in Hathor, it is just completely inaccessible.
There are of course some JavaScript errors showing up in the browser console.

So to restate and make it clear: This doesn't work at all in Hathor in the current form.

Ok, my apologies for not understanding that problem and using the wrong example. I still stand by the notion, however, that the client should control the rendering, not the server.

I completely agree with you. And I also think there should be no discussion at all about including a core feature which doesn't work in a core template.

Another observation because the thing felt quite slow for me (homeserver behind cable modem):
Each click will do a full "page reload" using Ajax. The whole div is requested again which is about 100-350 KB of data (just the rendered JSON response, without images) as far as I saw. The JED homepage however comes with around 50 KB of HTML data. I wonder where basically the same data gets inflated that much.
Looking at the raw response I see a lot of \t and \n which are probably not needed at all. Even after removing those and all the escaping stuff, the dashboard is still around 100 KB of data, which is still double the amount of JED itself and imho really a lot for an AJAX response.

Having tested the client, it's now more obvious that using HTML from the server is a problem. While this code is the only "bit" being added to the CMS, there are problems with what you see and those problems can only be fixed on the server. This is going to be a pain for the JBS because they are going to have to wait for the server to fix what amount to cosmetic issues, and it will cause confusion about where to report an issue (is the JBS going to act as first-level-support for the JED server?).

A simple example is that pagination support needs to be added. If the client was getting JSON data, we could easily deal with it here. At the moment, someone has to fix the server (who will be responsible for that, I don't know) for almost all the problems I predict will come up.

It's also loading a whole page each time which means we are no better than using an IFRAME strategy. The calls to the server, at the very least, need to be broken into three types:

1. The category tree
2. The list
3. The extension

I think this code is really, really good to demonstrate the "proof of concept", but in terms of adding it to the core, it's still too early to consider that.

Its great to see a discussion on this ! I am sure all of the team will be able to learn a lot from this & improve the implementation.

I would also agree on using RESTFUL APIs that output JSON & letting the client handle styling in the long run. Though this is on the surface, a major change it would not be very hard to implement.

The main thought process behind it was ( if i am not wrong) being able to quickly fix any issues in the UI , or roll out updates on the client side in the system without having to wait for a Joomla upgrade to do it ..

I would also like to see a Loader being put in place to show that there is some processing happening behind the scenes. I know this was considered, but its just missed out i guess..

The main thought process behind it was ( if i am not wrong) being able to quickly fix any issues in the UI , or roll out updates on the client side in the system without having to wait for a Joomla upgrade to do it ..

For a proof-of-concept, I think that's fine. For putting into production, I don't think that's a good idea. The CMS can release very quickly these days if it needs to (and there are ways to make that even easier through automation). At the end of the day, if you can nail a data service, it's hardly going to change and the maintenance should be very low. That allows CMS contributors to knock themselves out on browsing and installation features within the existing CMS contribution workflow. It also allows other people to experiment with alternatives that, one would hope, work their way back into the core offering once they are battle hardened.

The main thought process behind it was ( if i am not wrong) being able to quickly fix any issues in the UI , or roll out updates on the client side in the system without having to wait for a Joomla upgrade to do it ..

I fear that was the reason, yes. And I fear that will cause us problems as it can break existing (older) installations and templates. It looks a bit like "We want to do our thing here, without the CMS being able to control us" (not saying that is the intend, just my feeling). It's also not yet clear how the process will be for changes in the UI / server. Who will be responsible (JED, CMS, new group?), how will issues be handled (joomlacode, github?), where do we even report issues in the UI (like "doesn't work in Hathor")?

I would also agree on using RESTFUL APIs that output JSON & letting the client handle styling in the long run. Though this is on the surface, a major change it would not be very hard to implement.

I have to disagree here. It's the fundamental design that changes. The API will change. And this is exactly what should not happen after it has been released. If you're going to change it anyway, change it now. Do a RESTFUL API which structured JSON data now and let the client handle the styling. Now is the time to do this, not later. This will solve most issues we discovered so far and the others can be tackled down using regular processes.

You are right the API would change to start returning structured JSON instead of HTML. Beat maybe you can shed some light here ? I know this was discussed on the list earlier.. But even a copy paste from there would work :) I dont think i remember all the though behind it.

Sorry for not replying earlier to all good feedbacks in here, I have been focusing on implementation in this phase, but have read all comments as they appeared and tried to take them in account as realistically feasible while respecting the approved recommendations and implementation design.

Sorry for a bit lengthy reply too, if you have limited time and want the essence, jump to the conclusion after reading the following paragraph.

Just as a reminder, the technical choices made for Phase 1 has been focus on the feature for the Joomla User. The main goal of phase 1 implementation was to implement it without changing any of the current rules and implications regarding JED data, relationships between existing teams and with 3pd developers. We took in account to be careful to not change anything to the environment, so that there are no legal implications, changes required, and so on, so that there are no roadblocks or delays in getting this to the users. "apps-store" has been in discussion since years, and the only way to get it done without having huge discussions and lots of time for that was to implement it the simple way, not changing anything to the exposed data, not changing anything to the processes in teams, not changing anything to privacy concerns, not changing anything to processes.

So, here a collective reply to all feedbacks, with many thanks: We have included those that were possible for phase 1, and also took note of those concerning phase 2.

• Regarding feedbacks in comment 1 #1879 (comment) from @eddieajau:

  1. JSON instead of HTML format: We have switched to JSON format encapsulating the HTML output decided in phase 1, so that the protocol can be extended as needed in phase 2, after discussions and agreement by JED & OSM. I believe that JSON format replies with all details do require authentication with explicit agreement to ToS and traceability so that I could even recommend them for acceptance by JED and OSM. Industry giants use a lot of HTML webapps (google, yahoo, facebook to name a few), so I don't think that HTML can be considered a bad choice here for phase 1. Most importantly it's same content as on JED in same HTML format as on JED, destined to human reading, and not to machine reading. There is no advantage to use Apps* output vs http://extensions.joomla.org/ if someone would still want to data-mine the JED. To the contrary, data-miners will get more information from the website than from the Apps HTML output. With JSON, it would be a different story, and thus require authentication (which brings the privacy question).

  2. Server: is live and working well, thanks. Code is available in GPL on official joomla-projects repository.

  3. Overlap with new JED: There is no overlap here. This implementation is for current JED. New JED server-side implementation will be different, but can perfectly still be compatible with this client-side by design.

• Regarding reply in comment 2 #1879 (comment) from beat (that's me lol):

  1. We need to clearly restate again that this is a feature for the Joomla users (similar to other CMSes), not an API for developers and data-miners to the JED.

• Regarding feedbacks in comment 3 #1879 (comment) from @Bakual:

  1. The loading of a javascript file for webapps is industry-standard, and used on most sites, including www.joomla.org (which includes Google Analytics JS code), any site with "Like" or "G+" buttons, any site e.g. extensions.joomla.org implementing FaceBook Connect. If joomla.org gets hacked, you will face issues with many other aspects before this one, like the joomla script downloads, update-server issues, JED bad links and so on. We have installed the apps server on a distinct domain and distinct hosting account with distinct protections to insulate it completely from other joomla.org sites. That reduces the risks of Apps* being hacked way beyond other more complex joomla.org sites. Additionally, the javascript is only loaded only at the time when the user presses the "Install from Web" tab tip, not at every page like it's the case with Google Analytics or Facebook Connect or Google Plus buttons just to name a few. I do agree that structured JSON is nicer from an engineers-point-of-view, but the user won't see a difference in his use. Additionally, if joomla serves JSON instead of browser-side webapp, the risks are similar if joomla.org gets hacked: The hacker could serve bad links and thus bad code as well, so the JSON doesn't reduce risks significantly. We use https with valid joomla.org certificate, so that data can't be tampered on the way. Finally, remember that this feature has been done for the user, not as JED-data presentation API for the engineer that the user doesn't care of.

• Regarding feedbacks in comment 4 #1879 (comment) from @Bakual:

  1. We will be supporting compatible client versions in the server. And for sure latest supported versions of Joomla which implement this. I see no problem in stopping support of insecure old unsupported versions of Joomla, and displaying a "Please update your Joomla install to use this installation method. In the mean time, you can use any other installation method available". It is not a crucial installation method. The other methods are still there.

  2. I am aware that JSON data-structure is not very much more complex than HTML in JSON. However it distributes the complexity of the implementation to both sides, while here it's mainly server-side. However the complexity of a JSON-data oriented implementation regarding non-technical aspects (legal, strategical, approvals from all involved project teams) is magnitudes higher than simple HTML output that is similar in form and identical in current content, and thus does not require any changes.

• Regarding feedbacks in comment 5 #1879 (comment) from @eddieajau:

  1. I think it's great that you have ideas and a drive for phase 2 of this feature. Go forward, you have my support, but as you tell, it's at least 6 months of development work, and probably another 6 months of discussions before and after the implementation, so it's perfect timing for Joomla 4.0 and the new JED. Here we have a working solution, which looks great, works nicely, is using similar proven implementation methods as industry-giants are using, and that will be making the bridge until your new phase 2 implementation is here in time for Joomla 4.0 and JED "2.0".

  2. I have no secrets with JED, but I have talked with all instances that support this project before starting its implementation: PLT, CLT, OSM, JED and others, to make sure that we are compatible with their future directions. JED had already published that they will be rebuilding the JED, so no secrets there. Kind of funny to see how anything can raise unfounded suspicions...

  3. Hathor: Is supported. Additionally this new implementation is accessible, and can be used with only tab and return key buttons. So it is magnitudes more accessible to disabled people than any other installation method :-) , not only for free extensions, but also for registration-required and commercial ones. No download, no upload, full workflow from choice to install is smooth. So a big improvement for users with disabilities too. Actually feeling quite good about it.

  4. I agree that for engineering structured data is easier to handle than human-readable one. However here the "client" is the human, and not a program.

  5. Structured data will change more with the new JED than unstructured one, so I don't see an advantage to have structured data in phase 1, while we already know that structured data will change significantly with all new ideas of JED "2.0".

  6. When JED "2.0" is ready, we can perfectly improve/change client side for phase 2 in a dot-release for the LTS and STS versions under maintenance, and discontinue the then old phase 1 JED "install from web" service with an HTML message "This Joomla version is not maintained and supported anymore, please upgrade asap". Or we can still output in a compatible way from JED 2.0. to older Joomla installs. I see no issues here.

• Regarding feedbacks in comment 6 #1879 (comment) from @eddieajau:

  1. Version of Joomla is included in the url of the first script call, and thus multiple versions can be supported (e.g. with mod_rewrite rules).

• Regarding feedbacks in comment 7 #1879 (comment) and 9 #1879 (comment) from @Bakual:

  1. Thanks for pointing out about Hathor: We have now fixed that and Hathor now works fine, and additionally is more accessible than any other installation method.

• Regarding feedbacks in comment 8 #1879 (comment) from @eddieajau:

  1. I agree with you for phase 2 (only with authentication implemented), but do agree to not agree for phase 1.

• Regarding feedbacks in comment 10 #1879 (comment) from @Bakual:

  1. We have not yet optimized the server output and not switched on the CDN caching for development reasons. These 2 things are independant of the client-side, and will be done between beta and stable releases. Your hint to remove newlines and tabs is a good one, and with just 50 kbytes, it's acceptable even on mobile phones! Great!

• Regarding feedbacks in comment 11 #1879 (comment) and 13 #1879 (comment) from @eddieajau:

  1. The server is completely open-source on github, and improvement pull-requests are welcome. Right now the separation is very clear: what's outside the tab is the CMS, and what's inside is the server's responsability. With a JSON-data approach, it's more complex to see which side would be responsible for a given content and/or output just looking at the rendered output.

  2. We are better off than using an iframe: it works on apple mobile devices! And i see no need to have 3 http requests to the server for outputing one initial content. For refreshes/pagination and so on it's already planed to not update everything.

  3. This is much more than a proof of concept. It is a working solid implementation, respecting Joomla-leadership and community-reviewed recommendations and implementation design documents, as well as taking in account all feedbacks applicable to phase 1. Additionally, it has a great roadmap for phase 2, and without this phase 1 we wouldn't have seen the potential and raised the enthusiasm that has been raised for Joomla 3.2, as well as for phase 2 implementation. :-)

• Regarding feedbacks in comment 14 #1879 (comment) from @Bakual:

  1. The reason is flexibility. Is that bad ?

  2. The responsible team is the Apps* team, under the supervision of LT and JED, and with the help of infrastructure team, hoster, LTs and volounteers.

  3. Improvements can be done anytime server-side. Phases 2, 3,4 and so on can be deployed anytime in a dot release, keeping in focus the client of this feature: The Joomla user.

• Regarding feedbacks in comment 12 #1879 (comment) and 15 #1879 (comment) from @parthlawate:

  1. We are already using JSON as data structure, thus adding information, when wished and approved, will not break any existing installation. Versions are included in request, so evolutions are possible too.

Ok, that became quite long of a reply, but I hope to have referenced all feedbacks, and to have addressed all concerns raised.

As conclusion:

This is not just a proof of concept. It is a solid implementation that works well, also for disabled users, and brings a big plus to Joomla 3.2, putting it on paar with other popular CMSes for the extensions installation.

It is the result of years of thoughts, months of design and implementation, and leadership and community review.

It is something we wanted since long, and that is now here, ready for integration into Joomla 3.2.

There is no real security risks outside ones that already exist with joomla and extensions installation and update process, and JSON doesn't solve anything here.

Should we really wait another year for Joomla 4.0 for a technically more exciting implementation bringing the already existing feature to the users ?

I do not see any valid reason to reject this implementation, which has been done by an awesome team (Many thanks in particular to them, specially to @coolbung, @emavro, Gev) with an awesome support from all Joomla leaders, the JED, OSM, the PLT and CLT, and @porwig who has organized that this Year 2013 Joomla target gets reached in 2013! Many thanks to all of them too).

1.The loading of a javascript file for webapps is industry-standard, and used on most sites, including www.joomla.org (which includes Google Analytics JS code), any site with "Like" or "G+" buttons, any site e.g. extensions.joomla.org implementing FaceBook Connect. If joomla.org gets hacked, you will face issues with many other aspects before this one, like the joomla script downloads, update-server issues, JED bad links and so on.

Just a comment on that. I know that Google and others are also offering Javascript for inclusion on sites. But if I have to guess they run this on very secure and hardened servers where they make everything possible so the data served doesn't get compromised.
You sure don't want to compare your server, running on a Joomla CMS, with the servers from this companies.
It's true that there are other risks as well with update-servers and such, but if I have to guess again, the update-server probably isn't served by a CMS as well. It most likely is a simple file served by a webserver. Again much easier to harden such a server. Also it doesn't have the chance of launching an attack on the client by simply visiting a page in your Joomla backend, which is different if your server is hacked.

Structured JSON data with plain text response sure would be much more secure. The only thing that could be done is serving wrong links. But that would at least need the user to click on those links, while with your approach it may be enough to just visit the page.

Just don't take that to easy, there will be attemps to hack your server for sure.

Hi Beat. Thanks for the replies but it's clear to me this is just the way you and your team want to do it and you don't want to accept any help to do it differently. It's still a from me.

@Bakual,
Thanks for your reply. 3 small things to correct and looks like 1 to clarify:

1. We're not "taking it easy" as you say.

2. This is not "my server", this is on the joomla.org infrastructure, . Your judgement of levels of security based on guessing is yours, and I do not wish to comment on that.

3. Our main javascript file is a simple static file, same as most other mass services do.

4. I do agree that structured JSON is nicer from an engineers point-of-view, but as explained above, it doesn't bring anything to the current user UI, which is already awesomely designed by the Apps* team, Plus it doesn't match non-technical requirements for phase 1, as e.g. it really requires authentication to be usable properly (most of popular JSON web services had to switch to authenticating users).

Hi Andrew, No hard feelings here. Looking forward to your contributions for phase 2 when it starts together with the new JED.

Phase 1 implementation is now completed, matching the approved recommendations and implementation design.

Hmm, tested again with the branch from https://github.com/joomla-projects/joomla-cms/tree/feature-appstore-client

• The webapp is still very slow for me. 6 seconds loading time for the dashboard.
• IE11 is still loading the category pages very slow, sometimes over 10 seconds and the script hanging. Chrome however is fast after the initial 6 seconds for the dashboard.
• The data has been updated apparently or is live now. Can't tell that. I can now install my own extension succesfully after I entered the URL into the JED field. That's done well. Maybe the confirmation page could be styled a bit nicer but I could live with that. I'm still a bit disappointed here that we have to provide a package URL instead of simply the XML file. Especially for free extensions that would be a nice way of providing the URLs to the packages.
• I still don't like that the URLs shown in my browser statusbar are pointing to "http://www.mydomain.com/administrator/index.php?option=com_apps&format=json&view=extension&id=7256". This URL is just plain wrong. It should point instead to the JApps server. This happens because those are relative URLs in the source code, but they should be absolute ones. I'm aware that the JavaScript will pick up that relative URL and add the correct domain to it. But it's still wrong to have relative URLs when it should be absolute ones. I think changing that should be easy and would even make the JavaScript simpler.

• I still think there should be a link to the download page, at least if the "Install" button isn't shown. Because that will be the most important URL the user is looking for. Currently you only show the JED entry and the main developer page. So for extensions which didn't update the info in JED yet, this "Install from Web" doesn't help the user at all. He either has to go to the JED link and use the download button from there (like before) or he has to go to the developer page and search for the download section there (like before). Doesn't solve anything besides that you can skip Google (which is way faster and will bring either JED or the download page as first hits).

• Hathor is giving me an internal server error now when I try to access the installer. Errors logged in server error logfile:

PHP Fatal error: Access to undeclared static property: InstallerModelInstall::$appsBaseUrl in /.../administrator/templates/hathor/html/com_installer/install/default_form.php on line 13

So something is even worse now than before.

Thanks for your help on tests and your helpful feedbacks, @Bakual

1. CDN caching is not yet turned on on live server, and latest server-side optimizations are not yet on the live server. Once cache is turned on, everything except searches will be as fast as the fastest page. Additionally we are fixing a slow query (the JED database itself was missing a few indexes, that will be added too once staging tests are completed, which will also make the JED itself faster probably).

2. IE11: thanks for the browsers testing, we'll look into IE11 slowness (As JS files are served from the server, it's not a show-stopper for the client-side)

3. Yes, live server uses live data now, and JED is now supporting this feature, as you could see it works fine. We have added support for XML updater files following previous feedbacks from community on a list and/or tracker. This addition is currently under staging test and should be updated to the live server in the next days with a batch of other improvements suggested by the community and the Joomla leadership.

4. Yes, it's a good idea to remove or replace those links in javascript, it's an easy cosmtic win (No link or text is ok, but Apps server link should not be shown in the browser, as they are not for direct access). Thanks.

5. Falling back to the "Downlad" link of JED when install URL is not available is a good idea and helpful to the user. We'll add that. Thanks.

6. Hathor support is still in staging server and will go to live server as soon as Apps* team tests are completed.

We have added support for XML updater files following previous feedbacks from community on a list and/or tracker. This addition is currently under staging test and should be updated to the live server in the next days

Does that mean a new field in JED or will the current field accept an XML link? Will the title/description of the field be updated accordingly?

No link or text is ok, but Apps server link should not be shown in the browser, as they are not for direct access

Actually you can also show them. Everyone curious will be able to figure out those links anyway. At least it would make it clear to the user that the data is taken from an extern server, unlike the rest of the backend.

Also a note on the mobile view: It first shows the list of categories which means you need to scroll down a lot till you come to the search box and the actual extensions.
I'd assume that the user wants to see the search bar and the extensions first, especially if he has done a search already.
As a suggestion I would collapse the category list by default for mobile views.

I believe that JSON format replies with all details do require authentication with explicit agreement to ToS and traceability so that I could even recommend them for acceptance by JED and OSM. Industry giants use a lot of HTML webapps (google, yahoo, facebook to name a few), so I don't think that HTML can be considered a bad choice here for phase 1.

A note on this. If you look at the API from Facebook (to name one), you can get the information without any authentification at all with a simple API. See as example: https://graph.facebook.com/joomla. You can get almost everything available for public like this. Facebook doesn't hide that stuff.
Authentification of course is not an option at all for the "Install from Web" feature. Don't even think about this. It just doesn't make sense that a user will have to

1. visit JED
2. create an account there
3. go back the the Joomla backend
4. and enter his credentials here,

just to see the content which is available without authentification at all on the JED site itself. This would be a big no-go.

I don't see what the problem of a proper API is. Even if there would be dataminers, all they could get is information already present otherwise. There is no sensible data exposed. It would also be possible to set up a system on the server which could detect and block such robots, if you really insist on not feeding them. Or you could block them as soon as you see a site emerging with JED data.
Facebook apparently doesn't has a problem with sharing the data, why should Joomla have one? :-)

Authentification could be useful if one wants to show additional extension data, like reviews. One could restrict that to the extensions a developer owns. So it may be possible to show latest reviews on the developers page or stuff like that. But that for sure is for the future :-)

As requested by Paul Orwig, and on the basis that there is no clear consensus to merge, the best way forward is to package this as a separate and optional component.

Hi Andrew - I'm sorry but I don't believe I ever requested that.

Just to be clear, here is my request: Let's encourage the community to continue testing and giving feedback on the code that has been submitted, and let's allow the developers to continue working on any issues/enhancements in the time that's available to them. And then ultimately let's trust that the PLT and CMS maintainers will make a good decision about the best way forward (or at a minimum about what will be included in 3.2 beta).

Your request was to provide feedback here - that's all I did.

Here's my request: listen to the feedback you already have instead of asking for more hoping that the answer will change. There is enough feedback now that you and Beat should realise that a compromise is called for and that this code is not ready for core. There is nothing to loose and everything to gain by making this a separate component in the short term and that way all the work that has been done so far is not lost.

The reality is that this component wreaks of scope creep and adding bells and whistles. The first year of its life is going to be better spent outside the core so it can update faster, not locked into the 3.2 patches (not to mention what happens we 3.5 comes along and the uncertainty of whether 4.0 is necessary at this time). Once you have put it into 3.2 it is feature locked and you cannot "technically" add anything new or make wholesale refactoring to fix a major "oops".

It's a win-win for everyone Paul and it's the prudent thing to do given the number of variables and questions still in play. Why is that such an unreasonable outcome?

Hi Andrew - After reading your second comment, I can see that I misunderstood your first comment. I apologize for that! Hopefully this will clear that up:

When your first comment started with "As Paul Orwig requested", it came across to me that the rest of your comment was referring to points that I had made elsewhere. So my response was intended to make it clear that I didn't ever say those things I thought you were attributing to me.

Of course I did request people to come here and leave their comments. I am sorry that I misunderstood your first one here.