Toby
With the release of the 1.0 client, we also have a new release of the 1.0 server! There's no rush to upgrade, since the prior version is API compatible, but you'll probably want to upgrade soon to take advantage of the various fixes.
There are a bunch of structural improvements, and a few major architecture changes. The most notable one of these is that we've completely separated the registration piece from the sync piece. This is mostly for futureproofing - we plan to have additional services in the future, and this will alow you to pick and choose the ones you need, as well as version them separately - but also allows you to install just the sync portion and handle registration however you like.
The second major change is that we've discontinued support for SQLite in the main architecture. If you're using SQLite, you're far better off using the Weave Minimal Server (which is already compatible with 1.0 and doesn't have an update). It's at http://people.mozilla.org/~telliott/weave_minimal.tgz
One final tweak of note - the client for the user API uses a 1.0 version number (instead of 1) to make the two services match. Just edit the current /user/1 alias in your apache config to 1.0 and you'll be good to go.
The new registration server is here:
http://hg.mozilla.org/labs/weaveserver-registration
(hg revision 0575a21fbca2)
The new sync server is here:
http://hg.mozilla.org/labs/weaveserver-sync
(hg revision d7e22931c0fc)
Each instance has a README file that can walk you through the install process, and we've done a bunch of work to clean up the constants file to make it easier to understand and install. If you've have a fairly recent server, you probably don't need to mess with your database - check to see if the username column is an integer - if it is, you're up to date.
As always, the API documentation and some setup assistance can be found at:
https://wiki.mozilla.org/Labs/Weave/API
and we have a server mailing list at
http://groups.google.com/group/mozilla-labs-weave-server-users
where you can get install help and we can try to troubleshoot problems.
Happy Syncing!
I also want to ask since registration piece and sync piece are
separated now, what is the best way to deploy server files.
I suppose registration and sync folders must be under same
DocumentRoot? Otherwise I get 403 error for weaveserver-registration/
1.0/index.php.
I'm also getting a lot of 400 related errors, but apparently I'm doing
something wrong will try to figure it out latter, had enough for
now :)
Regards
On Jan 29, 2:47 am, Toby Elliott <telli...@mozilla.com> wrote:
> Just posted this message to the server blog.
>
> Toby
>
> With the release of the 1.0 client, we also have a new release of the 1.0 server! There's no rush to upgrade, since the prior version is API compatible, but you'll probably want to upgrade soon to take advantage of the various fixes.
>
> There are a bunch of structural improvements, and a few major architecture changes. The most notable one of these is that we've completely separated the registration piece from the sync piece. This is mostly for futureproofing - we plan to have additional services in the future, and this will alow you to pick and choose the ones you need, as well as version them separately - but also allows you to install just the sync portion and handle registration however you like.
>
> The second major change is that we've discontinued support for SQLite in the main architecture. If you're using SQLite, you're far better off using the Weave Minimal Server (which is already compatible with 1.0 and doesn't have an update). It's athttp://people.mozilla.org/~telliott/weave_minimal.tgz
> I am soo confused, all the documentation is messed up.
> Sync Setup and User Setup pages on mozilla wiki are different from
> what is in README file included with server.
Thanks for mentioning that; I cleaned up a couple inconsistencies from transferring from the old version of the docs to the new one.
> I checked dates, and I suppose the readme file included with server
> are more correct and up to date, right?
The README is more up-to-date, but less comprehensive. It's intended as a base guide for getting things running, whereas the setup pages go into detail about getting captcha keys, etc.
> I'm also wondering is http://hg.mozilla.org/labs/weaveserve obsolete
> now?
Yes.
> I also want to ask since registration piece and sync piece are
> separated now, what is the best way to deploy server files.
> I suppose registration and sync folders must be under same
> DocumentRoot? Otherwise I get 403 error for weaveserver-registration/
> 1.0/index.php.
DocumentRoots are entirely optional, and the two components are separate systems, and don't need to share anything. Just add a couple Alias lines in your apache config to point at the index.php scripts (and a couple more aliases if you want to support deleting accounts and password resets).
You should, theoretically, get a 403 for the address above. It should be at /user/1.0/
> I'm also getting a lot of 400 related errors, but apparently I'm doing
> something wrong will try to figure it out latter, had enough for
> now :)
A 400 error should also come with a response code, which you can look up at https://wiki.mozilla.org/Labs/Weave/1.0/ResponseCodes
Let me know if you have any other questions.
Regards,
Toby Elliott
I think there's an error in the README... Setting up an alias of
/weave-sync/1.0 results in a 404 as the weave client seems to as for
/1.0 ... As soon as I updated my alias to /1.0, weave began working again.
--
---------------------------
Jason Frisvold
xenop...@gmail.com
---------------------------
"I love deadlines. I like the whooshing sound they make as they fly by."
- Douglas Adams
Good catch. Fixed in the README.
Toby
I also have one proposition.
It would be nice that when/if you choose "Use Custom Server" then that
setting(at least server name) would be remembered. So when you next
time do start-over it will be already there. If pref
extensions.weave.pwChangeURL would be set at the same time to point to
the same server password-reset url it would be even nicer :)
Just my little toughs.
Weave was a brilliant idea, keep up the good work!
regards
Regards,
Toby
thanks, nice to hear that. I just seen roadmap for 1.1 and this and
much more is already planned, nice to hear that too.
In a year or so weave along with weave-identity and FF4 is going to be
really kickass product :)
regards
The installation process could have been smoother:
1) Extension tries this URL for captcha: /misc/1/captcha_html but
documentation contains only /misc/captcha_html alias.
2) Captcha must always be used, defining admin secret does not help,
neither defining WEAVE_REGISTER_USE_CAPTCHA as 0, fortunately provided
keys work fine (I was shown this message and did not know where is it
coming from "Invalid public key. Make sure you copy and pasted it
correctly.")
3) If you do not define properly aliases on the server, you may see
"Already in use" for username when registering - this is very
confusing, it should say something about wrong configuration, you can
see all possible errors masked in service.js:
if (data.status == 200 && data == "0")
return "available";
But at the end the server is up and running data is stored on it and I
just need to test how the sync will work.
Thanks for the server software,
Ondrej
> On Jan 29, 2:47 am, Toby Elliott <telli...@mozilla.com> wrote:
>> Just posted this message to the server blog.
>>
>> Toby
>> ...
>> Happy Syncing!
>
> The installation process could have been smoother:
>
> 1) Extension tries this URL for captcha: /misc/1/captcha_html but
> documentation contains only /misc/captcha_html alias.
Good catch. I've fixed the docs.
> 2) Captcha must always be used, defining admin secret does not help,
> neither defining WEAVE_REGISTER_USE_CAPTCHA as 0, fortunately provided
> keys work fine (I was shown this message and did not know where is it
> coming from "Invalid public key. Make sure you copy and pasted it
> correctly.")
Hmm, the code is checking for both definition and trueness of the captcha constant, and an admin secret, when provided, should override that. What is it you are trying to do? It sounds like a possible bug, but I have exactly that configuration working here.
Regards,
Toby Elliott
Mozilla