PDA

View Full Version : Central Ext User Extensions and Plugins Directory



jsakalos
17 Mar 2009, 7:09 AM
There have been discussion about resurrecting "Centralize User Extensions and Plugins" project (see the link below) and I think that opinions of Ext users and extensions an plugins authors are needed at this point, therefore this poll.

Understand please, that I'm not the main person behind the project. I do not have enough time to bring the project to the successful end, I only support the idea.

Goal: Goal of this project is to create Central Ext User Extensions and Plugins Directory.

Purposes:



To provide simple, nice and user friendly interface to the database of extensions and plugins for both authors and users.
To provide simple and fast methods to find extensions an plugins and get access to them.
To allow users to vote (thumb up or down) for extensions and plugins.
To provide authors and users information about popularity of extensions and plugins by seeing numbers of votes.
To allow authors to easily publish pointers, not files, to their extensions and plugins by filling a form in a couple of minutes.
To allow authors to make themselves known.

Here should come the detailed specification, the plan, of the application.

Anybody to take responsibility for the project?

What do you think about it (please vote)?

Reference thread: http://extjs.com/forum/showthread.php?p=303138#post303138

hendricd
17 Mar 2009, 9:45 AM
@Jozef -- Consider changing your Poll to multiple choice. I think we'd see a telling story if that were the case.

mschwartz
17 Mar 2009, 9:53 AM
Done right, it might be like Saki's examples page. It'd be nice to see a simple example of the extension working, as well as source code in HTML, PHP, javascript, css, or whatever other backend language.

jsakalos
17 Mar 2009, 10:17 AM
@Jozef -- Consider changing your Poll to multiple choice. I think we'd see a telling story if that were the case.

Unfortunately, poll cannot be changed, or I don't know how. What exactly do you mean anyway?

Scorpie
17 Mar 2009, 10:19 AM
+1 for the idea.

My thoughts about the plugins is that the main drive behind them should be to provide adequate information, running examples and code, and also some sort of knowledgebase containing best practises and guidelines.

These things should be hosted by one party, dedicated solely to preserving plugins and their references, as well as providing a base for future projects.

jsakalos
17 Mar 2009, 10:21 AM
+1 for the idea.

My thoughts about the plugins is that the main drive behind them should be to provide adequate information, running examples and code, and also some sort of knowledgebase containing best practises and guidelines.

These things should be hosted by one party, dedicated solely to preserving plugins and their references, as well as providing a base for future projects.

Do you have any ideas how to achieve that?

jsakalos
17 Mar 2009, 10:22 AM
BTW, please vote if you haven't done so yet, as +1 in the post text won't be counted as an answer.

Scorpie
17 Mar 2009, 10:25 AM
Do you have any ideas how to achieve that?

My idea would be that submissions should be voluntarily, but should conform to a set of *limited* standards, such as a simple example (that can be run from the examples folder), docs to accompany the plugin, the source code, author info, etc.

The whole idea centers around the principle of users contributing plugins, and other users contributing their experiences with the plugins. A combination of the sample page you run, combined with some sort of wikipedia, could a first step towards this idea.

Your plugins could be very well be the base for this idea, your plugins have a solid userbase backing it up, as well as enough people who have experience using them / modifying them which can be contributed back to the community.

mschwartz
17 Mar 2009, 10:26 AM
BTW, please vote if you haven't done so yet, as +1 in the post text won't be counted as an answer.

+2!

Scorpie
17 Mar 2009, 10:27 AM
Also, a very good reason for the hosting of these plugins on one site is the continuity of the plugins: numerous examples and extensions in the forums are outdated or simply do not exist after extended periods of time. This could also included as a goal for the resurrection.

jsakalos
17 Mar 2009, 10:35 AM
My thoughts about the plugins is that the main drive behind them should be to provide adequate information, running examples and code, and also some sort of knowledgebase containing best practises and guidelines.

I cannot resist to say a bit more about this. I think that that should be the responsibility of authors. I'm on the author's side of the coin and as long as you want me to publish a pointer to my extension, I say YES, why not. The moment you start to persuade me to post code somewhere I say NO. Not because I don't want to give my code out, you know me, I've given out a lot of code already, but because then I need to take care about that code.

So, I have my server, svn system, development system (workstation), deployment system where I can easily do tasks related to my extensions development, maintenance and debugging and you're telling me to start to use another "central" system. I just don't have time for that. Also, I think, this is primary reason why the first attempt to centralize ux has not been that successful.

Information, examples and knowledgebase is also the responsibility of authors, IMNSHO, users will vote anyway so if you won't provide what they expect, e.g. no documentation, you'll get thumbs down. A kind of natural selection, only the best win.

jsakalos
17 Mar 2009, 10:39 AM
The whole idea centers around the principle of users contributing plugins, and other users contributing their experiences with the plugins. A combination of the sample page you run, combined with some sort of wikipedia, could a first step towards this idea.


I like the idea, should I add it to purposes?

jsakalos
17 Mar 2009, 10:41 AM
Also, a very good reason for the hosting of these plugins on one site is the continuity of the plugins: numerous examples and extensions in the forums are outdated or simply do not exist after extended periods of time. This could also included as a goal for the resurrection.

Well, this is questionable because if one server is down all extensions are gone. If they are hosted on authors' servers, only the directory (list of them) is gone.

hendricd
17 Mar 2009, 11:05 AM
Unfortunately, poll cannot be changed, or I don't know how. What exactly do you mean anyway?

@Jozef -- It's clear just by looking at the current Poll results, that most would elect #1 and #4 if they could.

We've discussed this multiple times on numerous threads, and we're always left with the same fundamental problem: Open-source projects (especially extensions to them) lack the resource commitments that are enjoyed by our commercial counterparts.

Just thinking out loud here, but many extensions/plugins presented for Ext are generally very simple to understand/implement by even a novice developer. No real incentive there for the busy (but well-intentioned) contributor to follow a regimented submission process for what he may perceive as a 'narrow-use' addition in the first place (the entry/ongoing cost of documentation, support, BugTracking, etc is just too high).

Other thoughts:

Voting/Ranking:
Thumbs Up == constructive and a simple way to publicly acknowledge and identify even the simplest contribution of reasonable quality.
Thumbs down WILL NOT foster innovation or future contributions. For every one we "shoot down" this way, ten times that won't even bother with the attempt because of potential public ridicule. It never works.

Extension portal ownership and Maintenance. This has/always will be a fundamental stumbling block. This costs someone money and time. And there is no assurance that even the well-intentioned volunteer has/will-have (even in the near future) the financial resources to continue such an effort.

IMO: Such a repository should be provided and maintained by its primary benefactor: ExtJs.com (as most other mainstream extensible Javascript frameworks already do).

In short, the goals are indeed sound, but the "open-source beast" always yields different priorities.

jsakalos
17 Mar 2009, 11:11 AM
Doug, thank you for your opinions, they are very valuable.

(Thumb down is really not a good idea...)

jsakalos
17 Mar 2009, 11:16 AM
BTW, I've found out how to change poll. Any suggestions for opions 2 and 3?

Also, I could provide High Availability Cluster Server (double server with takover of failed node under 1 min) with full hourly backups connected to internet via redundant 1Gbit lines for hosting of the directory starting from the mid of this year free of charge.

Scorpie
17 Mar 2009, 11:20 AM
I cannot resist to say a bit more about this. I think that that should be the responsibility of authors. I'm on the author's side of the coin and as long as you want me to publish a pointer to my extension, I say YES, why not. The moment you start to persuade me to post code somewhere I say NO. Not because I don't want to give my code out, you know me, I've given out a lot of code already, but because then I need to take care about that code.


In my opinion, a combination of both can be achieved, code can be posted or a pointer can be submitted, which is up to the author. The author is free to choose which way he prefers best; contribution of code is not a commitment of responsibility for that code though. Improvements to code can be submitted in reaction-based systems, or sub-extensions can be based upon other extensions.

In no way can a code submit be a commitment for responsibility of that code; after all, open source community in my opinion is a free, open community with people making valueable contributions.



So, I have my server, svn system, development system (workstation), deployment system where I can easily do tasks related to my extensions development, maintenance and debugging and you're telling me to start to use another "central" system. I just don't have time for that. Also, I think, this is primary reason why the first attempt to centralize ux has not been that successful.


Of course this is not the way to go, in now such way should the central ux repo be used, it should not interfere with somebody`s workflow.



Information, examples and knowledgebase is also the responsibility of authors, IMNSHO, users will vote anyway so if you won't provide what they expect, e.g. no documentation, you'll get thumbs down. A kind of natural selection, only the best win.

The voting system should not be in the primary interest of this system; the voting can be used for rating the quality of the plugin, the relevance, the documentation or a combination of these. It`s up to the personal experience of the user which values the extension/plugin based on his credentials.

The responsibility of the author is a grey area; he/she can contribute just the code hoping it will help fellow developers in their aid, or he/she can contribute the plugin with documentation and examples, knowing it will give users a jumpstart using the extension and/or submitting new ideas for the contribution.

Just my 2 cents ;)

hendricd
17 Mar 2009, 11:27 AM
BTW, I've found out how to change poll. Any suggestions for opions 2 and 3?

How about:
Goals are sound.
Goals are lofty.
Just stick with the Extensions Wiki that Extjs.com already provides.
Let's have Extjs.com host something like this.
Never gonna happen.


Also, I could provide High Availability Cluster Server (double server with takover of failed node under 1 min) with full hourly backups connected to internet via redundant 1Gbit lines for hosting of the directory starting from the mid of this year free of charge.

Wonder if AIG will sell me a Life Insurance Policy on you, Jozef? ;)

Scorpie
17 Mar 2009, 11:29 AM
BTW, I've found out how to change poll. Any suggestions for opions 2 and 3?

Also, I could provide High Availability Cluster Server (double server with takover of failed node under 1 min) with full hourly backups connected to internet via redundant 1Gbit lines for hosting of the directory starting from the mid of this year free of charge.

Wow, how the heck did you get that! =D>

jsakalos
17 Mar 2009, 11:36 AM
Wonder if AIG will sell me a Life Insurance Policy on you, Jozef? ;)

Good point. ;)

jsakalos
17 Mar 2009, 11:37 AM
Wow, how the heck did you get that! =D>

What? That cluster? I have developed them and I have company that produces them.

mjlecomte
17 Mar 2009, 12:25 PM
Technically #1 needs slight amendment:


1. To provide simple, nice and user friendly interface to the database of extensions, plugins and examples. for both authors and users.

I added examples. Saki's current site is proof of this point. Maybe someone wants to just search for an example of how to do X.

I eliminated authors and users. Goes without saying that it's for authors and users, but also it is for what I'll call "publishers". There are many extensions out there that some authors won't add to the list themselves, old or new extensions.

Personally I'd like to see www.bugtracker.extjs.com and www.extensions.extjs.com subdomains get launched, but I doubt it's going to happen (similar has been requested before). Maybe Saki can open a similar subdomain on his site/server.

jsakalos
17 Mar 2009, 12:31 PM
Good idea MJ, to add examples. Let's wait for other say, then I adjust it.

jsakalos
17 Mar 2009, 6:52 PM
Wonder if AIG will sell me a Life Insurance Policy on you, Jozef? ;)

Code of the application must be public, data can be made downloadable, so if anything happened to me, community has to find another hosting but nothing would be lost.

jerrybrown5
17 Mar 2009, 10:59 PM
Assuming that we could come up with the perfect interface for this, there are other dimensions that we need to look at. I tried to cover them here.

Perhaps I am taking an overly simplistic approach but I feel that the *only* way that this will be successful for us to agree to all points of the following.


1) Common Ownership and Licensing of all user components

i) Piggy back updates or die. If a quality component needs to be updated and anyone can perform the update, it will avoid becoming useless. This would be the same for documentation. Some programmers will give quality components minus the standardized documentation/examples, in this scenario any person with a little motivation and free time can fix it.

ii) No more licensing questions. Everything must be under the same license, and we've all been through this at least once too many times.

iii) By golly, there is a devil in the licensing details. I do not have the details as to what is the best common ownership and licensing model so as to not interfere with the Ext licensing model, especially since the new Ext 3.0 licensing options are unpublished. Consequently, we are certain to fail in this department without Ext's explicit help.


2) Common Hosting equals Common and Reliable UI (User Interface)

i) Common Hosting is not optional lest we forget the failed Ext user extension wiki experiment also known as the 404 express. Although Saki, I and probably a few other programmers have adequate to enterprise level hosting facilities at our disposal, this is the exception not the rule.

ii) Standardization is key. Regardless of whether we choose to present the components by Saki's tree view way or the grid/list view way, they must all be presented the same way. From the end user's perspective everything must look like the same programmer did it. Only central hosting and presentation can ensure this.

iii) Submit to your King--UI. When we have to choose between what is more important the component author or the end user, we must error on the side of the end user since any and all work will be for naught if nobody uses it.


Best regards,
Jerry

jsakalos
18 Mar 2009, 2:27 AM
Thank you for your opinions, Jerry.

My idea is to give users something like "Google for UX". A place where they can find if the UX they need exists and links to it, with standardized basic info, if yes.

jerrybrown5
18 Mar 2009, 6:22 AM
My idea is to give users something like "Google for UX". A place where they can find if the UX they need exists and links to it, with standardized basic info, if yes.

Do you mean something like AjaxRain?
http://www.ajaxrain.com/tagcloud.php?tag=extjs#script

Regards,
Jerry

jsakalos
18 Mar 2009, 6:29 AM
Yes, but visually different.

You see, I doubt that anything keeping the extensions can succeed at this point. But I believe that something keeping the pointers, links is viable.

Like Google doesn't keep pages but allows you to find pages.

jerrybrown5
18 Mar 2009, 6:56 AM
Saki,

What you are referring to is an enhanced layout of the existing Ext component wiki, which if you ask me what the greatest problem with it is, I wouldn't say the lack of organization but rather with the quality of the external links themselves. Therefore, I am certain that we will find ourselves in the same boat if we take the same approach.

Furthermore, if we take this same approach then it is already done. Albeit slow on the page load, Ajaxrain already includes a component screenshot, links, user commenting and a thumbs up meter. (The screen is attached.) Plus, there is an x factor at play as well--if more ext component authors were to use a service like this then more non-ext programmers would see the power of this javascript library.

Regards,
Jerry

jsakalos
18 Mar 2009, 7:06 AM
enhanced layout of the existing Ext component wikiDo you mean this: http://extjs.com/learn/Ext_Extensions?


Ajaxrain already includes...Extensions are not registered there by authors, at least I've never registered mine there.

Let me ask you a question: What steps do you currently do if you want to find if an user extension doing BlahBlahBlah exists?

jerrybrown5
18 Mar 2009, 7:28 AM
Do you mean this: http://extjs.com/learn/Ext_Extensions?


Yes, a non-moderated wiki of user extensions.



re..ajaxrain
Extensions are not registered there by authors, at least I've never registered mine there.


There is a suggest button on the site but I haven't used it.



Let me ask you a question: What steps do you currently do if you want to find if an user extension doing BlahBlahBlah exists?

The problem with external links is that they have to be moderated very closely so that it doesn't become the full of dead links like Ext's ux wiki. Plus, as I mentioned before few authors have any right to be self hosting any content.

For this and all of the reasons that I stated in a prior post is why we need to go with a central ux solution unless of course we are going to have somebody responsible for moderating it and keeping everything working and who wants to do that.

Regards,
Jerry

jsakalos
18 Mar 2009, 7:37 AM
Yeah, the necessity of moderation is valid point. Things mess up if nobody is taking care...

mschwartz
18 Mar 2009, 7:41 AM
You should take care to not allow people to post malicious javascripts.

jerrybrown5
18 Mar 2009, 7:44 AM
Saki,
As I mentioned before I really like your personal implementation of Ext examples and components and if every component author had their site up to snuff like yours than the links strategy would be a no-brainer--but unfortunately that isn't the case.

However, as I said in another thread, until the ext community has something better, I think your site is the best and I would be willing to assist you with yours.

Regards,
Jerry

jsakalos
18 Mar 2009, 8:00 AM
I understand Jerry, however, if you click About on the examples site, you see:


Purpose of this site is not to replace, improve or build upon the official Ext Samples (http://extjs.com/forum/../deploy/dev/examples/samples.html), they are invaluable as they are. The whole purpose is: To provide examples requested by Ext users.
I understand that solution of "let's use the best there is and add to it" seems to be logical, neverthelss, we would mess the original purpose that would lead to the failure of both examples and added extensions in the long run. The examples site is successful because it has clearly defined purpose that it fulfills.

And, if we ever want something like that for extensions and plugins, we need to create new site and with another purpose. That is reason why I initiated talks about it.

Once we, the community, authors and users, will have agreed upon purpose, the hosting, coding and other things will be easy to solve and they will align to the purpose almost themselves.

mjlecomte
18 Mar 2009, 8:05 AM
Perhaps I am taking an overly simplistic approach
Sorry, with all due respect, but overly simplistic? Overly complex IMO. What I read from your list of requirements is to impose something more strict than the current ux repository.

I think the insinuations that only the "perfect system" is acceptable is a bit ludicrous. Hashing this topic over and over again until we're blue in the face to come up with some theoretical perfect system will never happen. Come up with a few core principles that are required and leave the rest to improve with time.

Saki maybe you should divide your list into what is immediately required and provide a separate list for those that should be added over time.

jerrybrown5
18 Mar 2009, 8:06 AM
I think we are talking it to death, so let's put it to a poll. And hopefully, we can agree on the choices. :)

* Ajaxrain-ish site just for ExtJS components--provides links to different author's site.
* Central UX that is centrally hosted with common ownership and licenses
* Central UX that is centrally hosted without common ownership and licenses

Lets update/add/refine these choices.

Cheers,
Jerry

btw..MJ, Experience dictates that it is better to plan and then code (especially something that involves a community effort and especially since we are here because the last two community efforts for user extensions (Ext ux wiki and Ext ux repo) did not meet their potential.)

jsakalos
20 Mar 2009, 5:19 AM
I'm sticking this thread for some time to get more votes.

Up to this point, community is not too interested in such project....

:-/

SamuraiJack1
20 Mar 2009, 9:24 AM
As for me, the main purposes of such directory (good term btw, no clash with SVN) - it is to stop the mess with user extensions. Let me specify what I'm meaning.

I uses many of extensions, which were developed by someone else (as any other Ext programmer I'm sure). Lets optimistically say, I'm using 10-15 extensions in total.

Currently there is no any standard on ux. So any ux can be named in any way, it can be packaged in any way, and it can be hosted anywhere.

If I want to keep all my those 10-15 extension up-to-date and synced with latests author's fixes - that easily becomes time-consuming, because I have to:
1) Find the bookmark for this ux and open the forum thread
2) Read the 1st post to know about the current state.
3) Read the several last posts to find - may be someone posted a fix to this ux?
4) Find the download link and download the file.
5) Possibly unpack the archive.
6) Rename the file and put it to my current workspace


Now lets imagine all my 15 ux's are in current uxrepo. If I want to update them I will:
1) Open the documentation page and find the ux.
2) Read the docs to know if there is a new version
3) Issue the svn "update" comman on my local copy.
4) Copy the needed files to my current workspace

Much straightforwarder process, even without any interface to database.
( I'm not saying we dont need the interface to database ) )

And how it can be (If the directory at last will move to 'beta' from 'initial alpha'):
1) I'm open my account in ux directory.
2) In account I'm open my subscription list and click 'download' button.
3) Unpack the archive and copy its content to my workspace (no renaming, because naming scheme is the same)


I understand if author finds that the publishing process is too heavy and he want to publish just pointers and description - that sounds perfectly reasonable. But that should be an option, not a primary use case.



Purposes:

To create a centralized storage for user extensions, open for anyone who wants to contribute
To establish an ux development standard (at least the naming scheme)
To provide simple, nice and user friendly interface to the database of extensions and plugins for both authors and users.
To provide simple and fast methods to find extensions an plugins and get access to them.
To allow users to vote (thumb up or down) for extensions and plugins.
To provide authors and users information about popularity of extensions and plugins by seeing numbers of votes.
To allow authors to easily publish also just pointers, not files, to their extensions and plugins by filling a form in a couple of minutes.
To allow authors to make themselves known.


What I'd like to see - is a "lightweight CPAN for Ext"

SamuraiJack1
20 Mar 2009, 9:32 AM
Btw - the non-official formulation of purpose - it is to easily keep those 10-15 uxs of everyone synced with latests fixes.

jsakalos
20 Mar 2009, 10:04 AM
I understand the points you make, however:


You assume that users will want to update extensions frequently. If I'm a user I'm after stability rather after new features so I update veeeery rarely and only in the case of troubles with the version I have.
You disregard authors. I won't put my code to another svn but I'm eager to put links to my extensions to a directory.

SamuraiJack1
20 Mar 2009, 10:46 AM
1. Almost always, I'm improving the uxs I'm using or fixing bugs in them. I'm sure everyone do so.
I'm happy to contribute my improvements back - in the form of patch to original sources. But if me and author uses the different code layouts (and there is no shared SVN repo) - that becomes a senseless process. Once (well, if) we'll have an ux coding/packaging standard - collaboration would be much easier - and everyone will want to update frequently.

2. Not at all - as I mentioned having an option to publish a link to external storable ux really is a must.
Also - its possible to add the whole author's development repo to authors svn account in uxdirectory (via 'svn-external' property, though it will require a common code layout).

jsakalos
20 Mar 2009, 11:09 AM
As Jerry already said, we can talk it to death, but look at votes 22 replies (only!). Judging from that, community is not very interested. Let's give it some more time...

mnemonic
27 Mar 2009, 1:04 AM
can i get a new component for timepicker?
somebody please help me....

jsakalos
27 Mar 2009, 4:01 AM
Wrong thread. Try to search Extensions and Plugins forum or write your own.

Arno.Nyhm
3 Apr 2009, 7:58 AM
Wrong thread. Try to search Extensions and Plugins forum or write your own.

but its a good use case of this repo. someone needs a update for a component.


my ideas for this repo:

i like to see it something mixed like:

- mozilla extensions:
--> central repo,
--> i get informed if there are new versions
--> easy to update (one click!) my downloaded files
--> approved functionality

- github
--> everybody host there code
--> everybody can create branches)

- wiki / forum / KB / FAQ
--> for documentation, and examples

francodacosta
4 Apr 2009, 10:31 AM
I do not share SamuraiJack1 view

I prefer something simple, like the firefox extensions site.

A few words about the extension, some screenshots, and a link to the extension page on the author website

It's easy, simple, and has proved to be a successful format.

As an author I think that a solution forcing me to upload code is a nightmare and adds unneeded complexity by forcing me to manage code on yet another location.

I do not mind people messing with my code (that's why it's GPL), but on a svn solution as suggested by SamuraiJack1, people will be messing directly on my files, committing changes and patches and that will make me loose track of what is done and why and most important it takes me the power to decide the direction of my project.

Also having links to the author website is a good way to generate quality traffic and maybe some kind of revenue and that, i think, is a plus for many authors.

I do not think this solution will be a "404 express" as referred by jerrybrown5, because it's not that hard do programmaticly check for broken links, if one is found the author is informed and the extension removed

I'm all if favor, and willing to help, of a "firefox extension page" type of solution

mjlecomte
4 Apr 2009, 10:39 AM
but on a svn solution as suggested by SamuraiJack1, people will be messing directly on my files, committing changes and patches and that will make me loose track of what is done and why and most important it takes me the power to decide the direction of my project.

I think you misunderstood. Anything you upload is in your own private svn location. Think of it as shared hosting dedicated to this project. Not all contributors have a site to store their contribution, and most don't make their available for updating a la svn.

jsakalos
4 Apr 2009, 11:35 AM
@francodacosta (http://extjs.com/forum/member.php?u=14787),

wow, first author with same viewpoint as mine...

I have something even better than firefox add-ons in mind ;). We have grids, forms, Ajax, searching, and other tools under our belt in Ext.

If you really have time to code it, I'll provide hosting.

SamuraiJack1
5 Apr 2009, 1:11 AM
I do not share SamuraiJack1 view

I prefer something simple, like the firefox extensions site.

A few words about the extension, some screenshots, and a link to the extension page on the author website

It's easy, simple, and has proved to be a successful format.


You are somewhat contradicting to yourself.

Almost any extension on Firefox extensions site (we are talking about https://addons.mozilla.org/en-US/firefox, right?) has an "Add to FireFox" button, with which you can add this extension to your browser with 1 click. And later, Firefox will check for new version of this ux and will allow you to update it with 1 click.

So, when we are talking about "successful format" we are actually talking about these features, and not about the ability to create a link to your personal site.

Btw, how many extensions of other authors do you personally use in your projects?

jsakalos
5 Apr 2009, 2:22 AM
My 2 cents...

Here started a debate about success of Firefox add-ons page and about the idea of taking this page approach to create our success. It seems that taking model of one success to create another success is the good idea. Well, I think that our situation is different.

Firefox add-ons is aimed to end users and our directory is aimed to web developers. End users can and do operate on the basis of "what is new is good", software companies even push them to think this way to sell more of their products, but what is real the value for me, as a developer is stability. Once I develop an application I do not want endless debugging caused by an (semi)automatic updates of user extensions introducing new (possible) bugs.

What I want from authors of extensions I use as a developer? Hi quality code, brought to the point where it runs bugs-free in my application, nothing more. I do not want them to add features every week, I do not want to update the new feature-richer extensions into my application (I haven't used new features in the original application anyway because they hadn't existed yet).

One-click installation is also not point to me, I'm a developer, I'm a pro and my application is big and complex anyway, major part of it written by myself so finding an another authors code and integrating it is not a problem. I remember times when there was no Firefox + Firebug, just Mozilla, and when I needed Venkman Javscript Debugger, I found its source and compiled it myself. Developer must be able to know, find and use his tools, or he is not a developer.

My viewpoint as author: All my extensions were created "because I needed them", not for others to make their life easier, not to make my living, not for prestige, not for any other reason. The fact that I've given them out to community is only my good will. Any attempt to force me to do anything more with them, to upload and maintain another copy of their code immediately fails. Why should I do it? Life of developer is hard enough already, unpaid hours mean less income, donations do not cover the loss (if you got only $1 donation for each development hour another developers saved with your extensions you would be a rich man, but it is not the reality), day still has only 24 hrs, body needs some rest and sleep, so why?

SamuraiJack1
5 Apr 2009, 3:29 AM
If only you'd have an experience with Perl you'd understand me..

In perl world, there is a CPAN (http://cpan.org/), which contain about 56000 (fifty six thousands) of modules (smth about that).

Each module has a documentation and a test suite, so the bugs are not re-introduced and its safe to upgrade.
Each module has an issue tracker, so the authors and users can communicate.

And any module can be installed with simple command:

cpan install ModuleNameand updated with:

cpan update ModuleNameBefore coding any task in perl, I'm checking CPAN and in 95% of cases there is a ready-to-use solution in it. Sometimes the solution is almost suitable for me, but it misses some feature. In this case I'm adding this feature and sending email to author with suggesting to add it to original distribution (sometimes they even reply:) ). Programming in Perl is about combining the pieces of code together.

As I mentioned earlier, I'd like to see something similar for Ext.



My viewpoint as author: All my extensions were created "because I needed them", not for others to make their life easier, not to make my living, not for prestige, not for any other reason. The fact that I've given them out to community is only my good will. Any attempt to force me to do anything more with them, to upload and maintain another copy of their code immediately fails. Why should I do it? Life of developer is hard enough already, unpaid hours mean less income, donations do not cover the loss (if you got only $1 donation for each development hour another developers saved with your extensions you would be a rich man, but it is not the reality), day still has only 24 hrs, body needs some rest and sleep, so why?

Sure, that sounds reasonable, though you described only "one side of the coin". Another side is - how many hours you saved with community extensions?

Don't think too much, because your code is much better than average extension (which is just a forum post: "hey look, here is my cool ux, it works!" with attached piece of javascript).
While so, there is no good reasons to contribute - you are giving much more than receiving.

Such situation will persist, while there is no general ux coding/publishing standard.

This standard is also the answer to "maintain another code copy" argument..

ry.extjs
5 Apr 2009, 6:06 AM
I don't understand what all this debate is accomplishing.

We all want a searchable, central repository for getting extensions. As far as coding practices/standards go, why not just have an approval process? There could be a few administrators who could approve an extension, or better yet, simply a button on the extension's page that would allow everyone to vote on whether or not the extension meets the requirements of the central repository. If enough people decide that the extension does not meet the requirements, it is removed. The same goes for the usability of the extension. Like jsakalos had mentioned, a simple voting system would take care of this as well.

The repository need only contain the extension's files and documentation. Perhaps a donation feature, like the current repository, could be implemented. But that's it. Anything else, such as an extension issue tracker, would put an extra burden on the developer. Like jsakalos said, this is a place for developers, not end users. We are creating extensions for own projects and sharing them out of good will. If you want a feature, you add it yourself.

Now, if there was a way to offer paid support through the central repository, that may be a different story. But that's opening up an entirely new can of worms.

That's my 2 cents.

francodacosta
5 Apr 2009, 3:51 PM
Well, my idea of what this extension directory should be is very simple

Beside the usual search, tags, and category each extension listed should have

Title
Description of its purpose and features
Ext (and other) version requirements
Rating system (5 star rating system)
Screenshots
Link to support (forum, wiki, email, whatever the author chooses to make available)
Link to download page
Link to demo page
Author info


The only mandatory fields would be Title, Description and download

This way we do not force anyone into coding according to an imposed standard, no files are stored, just pointers to the extension url.

All the problems about poor or broken code, can be solved by the rating system, an extension with 50 one star votes is yelling “Problems!!!”

Non existing extensions can be easily removed by an automatic link checker

This is a fast, easy and clean way to keep all extensions organized and easy to find while keeping the author in control in an effortless way

jsakalos
5 Apr 2009, 11:23 PM
All is fine and matches the original goals, only it could be composed of Ext components (grid, tree, form, etc. Maybe you have that on mind but the above infers some classical technology like wiki or wordpress.

Arno.Nyhm
6 Apr 2009, 3:07 AM
Here started a debate about success of Firefox add-ons page and about the idea of taking this page approach to create our success. It seems that taking model of one success to create another success is the good idea. Well, I think that our situation is different.

the idea here was the points:

- easy to use
- central point
- current state with (hopeful) bugfree extensions


Firefox add-ons is aimed to end users and our directory is aimed to web developers. End users can and do operate on the basis of "what is new is good", software companies even push them to think this way to sell more of their products, but what is real the value for me, as a developer is stability. Once I develop an application I do not want endless debugging caused by an (semi)automatic updates of user extensions introducing new (possible) bugs.

how to update the extension can be different then on the mozilla add-ons and a full automatic update dont fit the needs.

but i think more of functions like this:

- inform me if there are new a new version (or a bug fixed version) of a ext-extension is available
- easy way to update my code with the new version if i like it (see my next posting)



What I want from authors of extensions I use as a developer? Hi quality code, brought to the point where it runs bugs-free in my application, nothing more. I do not want them to add features every week, I do not want to update the new feature-richer extensions into my application (I haven't used new features in the original application anyway because they hadn't existed yet).

i look not so much new features, but the leak of a forum based extension is that i never have a central current version. all bugfixes i need to read through all postings in the forum and then combine it with the first posting in the thread. thats annoying.

so the features should be in the repository:

- always current state of the plugin
- easy to upload/send bugfixes to the repository with approving by the author (or if the author not more interested in contributing support then from otherone - so the bugfixes not lost in space because of the not more interested authors)



One-click installation is also not point to me, I'm a developer, I'm a pro and my application is big and complex anyway, major part of it written by myself so finding an another authors code and integrating it is not a problem. I remember times when there was no Firefox + Firebug, just Mozilla, and when I needed Venkman Javscript Debugger, I found its source and compiled it myself. Developer must be able to know, find and use his tools, or he is not a developer.

there are you right, every developer has to know whats going on and need the control over the source.

but with little helpers its better to upgrade some extensions.

Arno.Nyhm
6 Apr 2009, 3:10 AM
for the repository it is good to have also some nice functions? or tools to:

- easy add an extension to my codebase (update from repository)

- with a given directory structure and then we only call the extension like this simple statement:
Ext.includeExtension('ext.ux.form.MultiTextField');

then all needed files should included like js files and also css files.


also a small dashboard where i see:

- which extension i have installed
- which extension is now on repository and can be updated



for example in ruby on rails you can easy install, update and include gems (the ruby on rails identifier for plugins)

Arno.Nyhm
6 Apr 2009, 3:12 AM
a decentral storing of the plugin code has the problem to get the current source of the plugin. in each authors page you have to find out how to get the code. thats also annoying. so a central repository including the code is much more easy

francodacosta
6 Apr 2009, 3:58 AM
a decentral storing of the plugin code has the problem to get the current source of the plugin. in each authors page you have to find out how to get the code. thats also annoying. so a central repository including the code is much more easy

That way you are forcing author to manage their code in yet another location, for me that's a problem.

Although I update my site with new versions I'm not willing to have to update other locations, that's why I defend the "pointer to site" idea.

Also as a developer I'm used to find other code and implement it, and I see no problem in continuing to do so

I'm more willing to update the directory page of my extension to say there's a new version than uploading files there, just for others convenience.
That's because if I forget to update the page, no harm is done, but if I forgot to upload the files no one will use the new version

jsakalos
6 Apr 2009, 4:03 AM
a decentral storing of the plugin code has the problem to get the current source of the plugin. in each authors page you have to find out how to get the code. thats also annoying. so a central repository including the code is much more easy

No, I won't put code of my extensions to a repository. I've explained it many times why.

Arno.Nyhm
7 Apr 2009, 3:16 AM
No, I won't put code of my extensions to a repository. I've explained it many times why.

so we can design the repository for both:

1) developers like to have its own place for the code
2) developers like to commit to a repository (like me)


for the first solution there can be an "autoversion" info: the repository checks each week or on demand the source (via a given link to the source or to a versioninfo.txt) and then the repository can inform subscribed users about an update.

all can be possible and fit all needs ;-)

Arno.Nyhm
7 Apr 2009, 3:20 AM
an good (or bad?) example how frustrating "non-repository" can be:

http://extjs.com/forum/showthread.php?t=37241
E2CS-EventCalendar (v0.0.12)


download link: http://e2cs.mm-mendez.com (http://e2cs.mm-mendez.com/)

Warning: Cannot modify header information - headers already sent by (output started at /home/mmmendez/public_html/e2cs/wp-includes/default-filters.php:198) in /home/mmmendez/public_html/e2cs/wp-content/plugins/wp-multilingual/multilingual.php on line 1001

demo link: http://scimx.net/cms21x/e2cs/samples/sample.htm

Not Found The requested URL /cms21x/e2cs/samples/sample.htm was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/1.3.41 Server at scimx.net Port 80

mschwartz
9 Apr 2009, 5:04 AM
Might I suggest:

http://www.vbulletin.org/forum/showthread.php?t=196819

and especially this one:

http://www.vbulletin.org/forum/showthread.php?t=203028

prometheus
12 May 2009, 12:47 AM
Hi,

It`s good to see this topic and these goals (I voted). In my reply`s topic I think about a solution like http://drupalmodules.com/ for UI, it`s very easy to use, but support-infrastucture of drupal modules in the official site is good enough too I think. The combination of the two is the best way I think:
Its have all what we want (repository, wiki, issue tracking, etc.)
UI have all what users want (polls, votes, as good as fast frontend)
All of these are an optional base to jump to many other ways, for example IDE/RAD updaters to get ExtJS eXtensions from a central place by standard infos.
I voted to lets ExtJS.com somethink like that because I think it`s a point in my idea if we want an official, standard, centralized base infrastructure. These problems are not only our problems but users problems and therefore it`s a problem for ExtJS too. A light-handed minimal management is required if we want that if ExtJS is a successfull platform to long-long time. It`s more about this question/topic I think, ExtJS has a progressive-growing community, I think it`s more progressive what the the community, the developers and this place of nowdays can handle. The independent UX repo is a good first step but it`s not enough now for community - I`m not a false if I say that UX repo died I think, there are tons of UX`es circulating in Ext forum and over the net as all you see but UX repo has only some of these UX`es.

Ok it`s time to summaring what I said: We have the world`s best web UI but we not having a useable infrastructure for support the communiy`s growing, so we need infrastructure to do that - first of all before. After we have that, we can open a project for develop the UI frontend and backend, but this is requires a project leader - in here I think it should Saki - to set down the basics, a summarized specification, a roadmap, optionally a coding standard, etc. Community has enough well-qualified developer to drive this project out I think, there is no need to a one man`s army do all that.

Thanks for able to said all,
regardz,

jsakalos
12 May 2009, 9:01 AM
There was a "marketplace" announced on Conference so I'd wait to see what it's going to be.