Re: [orion-dev] getting started playing vs getting started transitioning

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

We have been focused almost entirely on
getting the remote-hosted server scenario working well. In this world users
never configure a server or have to worry about file paths. The "local
server with allowedPaths" approach was only intended as a stop-gap
to get us going on self-hosting Orion development. As such it is rough,
unpolished, and unfriendly. I think after we get this month's release out
the door we'll need to step back and really think about how we prioritize
fully cloud-hosted vs hybrid local server scenarios. The cloud approach
definitely cuts out a large majority of potential adopters, since almost
every existing project out there has tools they use that won't be available
on Orion Hub. For example, fbug uses SVN, which means you're not going
to be able to use a hosted model until there is Orion SVN support, which
nobody is working on. Lots of projects use a mix of technologies beyond
html/css/js, which we likely won't see supported for a long while. So,
I think we'll need to seriously consider improving the hybrid local server
scenario or we'll never get the adoption we need to build all those other
tools.

Having said that, it still feels like
you are feeling an inordinate amount of self-hosting pain compared to many
Orion developers that are also running local servers. One thing to keep
in mind is that you should never need to blow away and recreate your orion
workspace (the "serverworkspace" directory if you are using a
built server, or the "{workspace_dir}/../foo" directory if you
are using the launch configuration). You should be able to just point a
new server at an existing workspace and go. For example the procedure I
use for upgrading orion.eclipse.org is roughly:

rm -fr eclipse_old/
mv eclipse/ eclipse_old/
unzip eclipse-orion-I2011xxxx.zip
cp -r eclipse_old/serverworkspace/ eclipse/
cp eclipse_old/orion.conf eclipse/
cd eclipse
orion

You should only ever have to "set
up"  that workspace once. URLs of your stuff should remain stable
across builds because the workspace is remaining the same. I wonder if
this is what you're missing which is making your self hosting setup so
clearly painful?

John

"John J. Barton" <johnjbarton@xxxxxxxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx

06/08/2011 12:08 PM

Please respond to
johnjbarton@xxxxxxxxxxxxxxx; Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx>

To	Orion developer discussions <orion-dev@xxxxxxxxxxx>
cc
Subject	[orion-dev] getting started playing vs getting started transitioning

This is just a comment out of frustration.

I can see the top level page adding features for users to get started 
with orion, github, initializr, upload zip. But from my perspective 
these are practical only for a quick look around. As Orion advertises 
prominently across the bottom, "beware".  Realistically
I need to work 
with Orion + some fall back plan (eg eclipse) for some time to come. 
Unless I am missing something, this means working with 
orion.file.allowedPaths + file links, a solution which (let me try to 
say this nicely) does not put orion in the best possible light.

Maybe this is already in plan, but some suggestions:
1) allow and encourage (only) forward slashes in file paths in 
orion.conf. Java and Windows API work fine with forward slashes.  Maybe
this works but the docs encourage double backslash and claim we should
enter exactly the same path in orion.conf and in the file link dialog 
(oh, but not *double* backslash so it's not even exactly the same path).
2) get rid of the file linking dialog box all together.  It allows
arbitrary text input but the server does not. The dialog should offer 
only the entries in the orion.file.allowedPaths since this is all the 
server will allow. That would eliminate user errors from text entry and
it would give feedback on the orion.conf values.
3) Allow the user to navigate down the allowPaths value to select a 
branch other than root. (otherwise they may be burnt by bug 348040).
4) Obey the link name given by the user. If I say "fbug" as the
link 
name I don't want "/a" or "/J", I want /fbug. And I
sure don't want a 
different value if I create the "same" link later.

Ok, now back to renaming all of my URLs.

jjb


_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev