Well just to complicate things :twisted: although no new Explorer features are planned at the moment … That does not mean that there won't be any. For example the group admin console in Explorer was overhauled fairly recently. And there's ongoing improvement and bug fixing happening all the time. And as you point out Share does not yet have all of Explorer's functionality.
Hmmm. Well, that's too bad. Share is at least one generation in basic functionality behind Explorer, and it also does not scale as well as Explorer does.
Isn't that more of a reason to concentrate on Share development and make sure all of Explorer's functions are available via remoteable APIs; rather than force people to use Explorer?
I'm not sure what you mean with the scalability comment - Share can be deployed on (one or more) separate Tomcat servers and distributes more processing to the client's browser rather than the Repository. Did you have a particular use case in mind?
I'm not sure what you mean with the scalability comment - Share can be deployed on (one or more) separate Tomcat servers and distributes more processing to the client's browser rather than the Repository. Did you have a particular use case in mind?
I didn't mean performance scaling. I meant enterprise scaling with the number of people, functional areas and sub-organizations. I work at a small university with a number of colleges and business units. Many functions span the colleges (admissions, administration) and many are particular to a business unit.
Administrative scaling: You are currently an administrator or you aren't. If you are, you can do everything; if not, then you can only manage documents and spaces. There is no mechanism for delegation, scoping, or range. This is an issue with Alfresco in general.
1) All administrators have access to all category tags. You can't carve out a subset and allow only some sub-trees to be administered by a sub-group, except by gentleman's agreement.
2) All administrators have access to all users.
3) All administrators have access to all …
Site scaling:
1) Share does not have sub-sites. Strongly related sites, such as all of those run by the Financial Services Division, are tied together by some artificial, unenforceable, funky naming scheme, such as a name prefix – fsd_students, fsd_bookstore, fsd_whathaveyou. Considering that those sites should also be further partitioned in larger areas, and the funkiness just gets worse.
2) The Share interface does not out-of-the-box support delegated rights for creating or naming of sites. Consequently, anybody can name a site anything, perhaps colliding with the use of a different business unit. Namespace management then also requires that you get the name right the first time.
3) A typical use for a Share site is a working committee, such as College of Law Student Retention Committee. We have, perhaps a thousand such working committees. So, our naming convention would be that col_studretention is the site name. Over in the College of Education, someone creates coe_studentretention. The Department of Anatomy has its committee for retention, because of recent retirement of a well-loved professor (fictional), so it would be com_doa_studretention. And on and on and on, for thousands of committees, task forces, projects, working groups, etc.
How well does Alfresco fare with thousands and thousands of top level spaces? Not very well, performance starts sucking after a bit. That is why file hierarchies get introduced. Namespace management is only one of the reasons.
Multi-tenant is not an answer either. It partitions the problem but in the wrong way.
There's some interesting stuff here. Could you raise this in JIRA please (tends to get lost on the forums otherwise), so I can make sure our Product Manager has visibility of these issues.
I received an e-mail with the following comment supposedly from someone who works at Alfresco:
The book is right, but Alfresco Explorer won't go away for a long time yet. It is getting no further development, just bug fixes.
We are not sure yet how many development cycles it will take to completely replace Explorer with Share, probably another 2 product release cycles, so 3.4 and then 3.5. At that point everything should be set to deprecated Explorer.
Well someone probably needs to be more careful about what they are saying.
Up to the last sentence agrees with what has already been said on this thread.
But
At that point everything should be set to deprecated Explorer.
In my opinion there's no way Explorer will be deprecated or "unsupported" in two releases' time. In order to deprecate Explorer, first Share would need to reach feature parity with Explorer and then all the paying customers need to migrate to Share. I don't imagine either of these happening any time soon.
Well someone probably needs to be more careful about what they are saying.
Up to the last sentence agrees with what has already been said on this thread.
But
At that point everything should be set to deprecated Explorer.
In my opinion there's no way Explorer will be deprecated or "unsupported" in two releases' time. In order to deprecate Explorer, first Share would need to reach feature parity with Explorer and then all the paying customers need to migrate to Share. I don't imagine either of these happening any time soon.
Thank you for the information and for correcting what this other person says. But I'm wondering, is there some type of official statement or 'roadmap' from Alfresco that defines Alfresco's plans for its software?
Project SWIFT is reasonably understood now. And more details will probably be added in the next couple of weeks.
The next project, CUMULUS, is far more vague although one or two bits of it are in progress.
Any further out than the next couple of releases is in people's (Alfresco's and the communities) heads. Yes there are lots of ideas, proposals and possibly prototypes but it is little more than "wish list" that far out.
Ok but what about this entry on the 2010 Roadmap?:
Enhancements for 2010 Improved usability via new Document Management Client for the Alfresco Repository
It clearly addresses a "new" Document Management client (Alfresco Explorer alternative?). Or is Alfresco Share already being addressed as the "new"" Document Management client at this point?
Guess what it boils down to is if and when will there be a completely Surf (and perhaps even partly CMIS?) based Alfresco Document Management client that can be used as a real alternative to Alfresco Explorer (jsp based)? That means containing all or almost all functionality of the jsp based Explorer.
