Brian,
I've read this, and your proposal on the Cosmo list.
it seems like a fair amount of work and I don't see the benefit. It's
not like we have such a heavy-weight application that much is to be
gained by un-deploying different parts of it. We can get the same uri
namespaces you suggest within a single web-app. And if we don't want
the links between the different webapp sub-sections....we can just
get rid of them, and make people go to "/cosmo/admin" for admin
related tasks and "/cosmo/pim" for pim related tasks. We could have
all the appearances of separate web-apps without all the work.
I basically just am concerned with yet-another-big-arch-change that
will slow down momentum, but not really gain us much.
Bobby
On Nov 6, 2006, at 4:47 PM, Brian Moseley wrote:
On 11/6/06, Priscilla Chung <[EMAIL PROTECTED]> wrote:
That's fine. One of the questions I've been pondering is if the users
who would use file sharing might also be a casual collaborator (CC)
target user.
i think there will be some crossover, but probably not much.
1. Opposed to having login checkboxes, use separate subdomains for
capabilites. This is the model followed by a number of web apps, for
example calendar.google.com, mail.yahoo.com. A user may login to any
google of google's 'properties' such as gcal or gmail, enter the
subdomian url of another property and preserve their login status.
sub-domains is not something we can mandate as software providers.
using a technique like that is a choice of the deployer, not the
software vendor.
that said, i have another idea. we could separate out the repository
browsing ui into a separate webapp, integrated into snarf, and
separately downloadable as a war file from the core cosmo war file.
heck, we could even do this with the admin and cc uis as well and have
a completely ui-free core cosmo webapp, which i think would make jared
philosophically and metaphysically happy ;)
this would let administrators mix and match whatever uis they want,
and it would give deployers a little more freedom with proxying and
sub-domains and so forth.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
