Posted: Mon May 18, 2009 6:34 pm Post subject: Re: some first impressions
narf wrote:
2. When Gust's upload fails, only the message key "upload.error.uploading.max.size" is shown, not that key's matching error text. I can not reproduce this on neomobile-test-backup2.neooffice.org. For me the error is "Sorry, an error occured while saving data"
This problem is really this problem. Gust has set his preferred language in the System Preferences application to language other then English whereas narf's Mac is set to English.
Posted: Mon May 18, 2009 10:52 pm Post subject: Re: some first impressions
narf wrote:
Can you provide us with a sample document that fails to upload? I have not been able to get a document under 10MB that reproduces the upload problem consistently.
Posted: Mon May 18, 2009 11:12 pm Post subject: Re: some first impressions
pluby wrote:
That is really where the difficulty is: once a URL is unprotected, it is open to anyone and you are really hoping that no one finds your secret URL.
Correct. But the docs I distribute this way are not classified. They are merely discussion texts or draft versions of project reports which will end up in the public domain anyway.
pluby wrote:
Although it is a little more hassle, one option is that you can have your trusted circle of people create free NeoOffice Mobile accounts from their web browser or mobile phone. The free accounts would not be able to publish, but they would be able to view any files that you decide to share with them.
I have been thinking of this approach, but I'm afraid that's too demanding for my contacts. They'll just reply me: please send it by mail now and save me the hassle. And then in a subsequent message: can you send it again, I couldn't open it. And so on. And finally I'll upload it back again to my public webspace...
But it's not only that we the people are just lazy. There's also the issue of distributed administration of groups. In some cases I want a group of people being able to access a doc, without knowing who's exact a member of the group. Just as an example: I have a discussion note that I want to forward to the board. I just address my message to a mailing list theboard@thecompany.com. I know that someone else keeps the distribution list updated such that all board members are subscribed. Even if every board member had a NeoOffice account, I wouldn't know who to give permission to access my document. We would end up in a similar situation: hey, I can't access it, could you pls. send it by mail? And so on.
Posted: Mon May 18, 2009 11:27 pm Post subject: Re: some first impressions
Gust wrote:
pluby wrote:
That is really where the difficulty is: once a URL is unprotected, it is open to anyone and you are really hoping that no one finds your secret URL.
Correct. But the docs I distribute this way are not classified. They are merely discussion texts or draft versions of project reports which will end up in the public domain anyway.
I was not saying that your idea was a bad or infeasible one. Instead, I am just trying to make sure that we understand the use case so that, if we ever add such a feature, we can figure out how to handle any bandwidth or other costs.
As we continue through through the Preview phase, we will take a closer look at this proposed feature.
Posted: Mon May 18, 2009 11:38 pm Post subject: Re: some first impressions
Gust wrote:
[*]I don't really get the concept of sharing. It seams to me that you can only share a document upon initial saving, which is a limitation anyway. I didn't manage get a doc in shared mode (whatever that may mean).
This is a good catch. Although NeoOffice Mobile allows you to rename a file, you cannot move an existing file to a different folder. Hopefully, once things settle down, Tim can take a look at that and see if that feature is feasible.
Gust wrote:
[*]It would be nice if login & password were saved in the preference files, so you wouldn't have to enter them at every startup of NeoOffice.
I think I will need to ask to Ed if this is feasible. I know that we can store user names and passwords in your Mac OS X user keychain, but I am not sure how we can get that information to and from Apple's embedded WebKit browser.
Posted: Mon May 18, 2009 11:45 pm Post subject: Re: some first impressions
Gust wrote:
narf wrote:
Can you provide us with a sample document that fails to upload? I have not been able to get a document under 10MB that reproduces the upload problem consistently.
Attached.
Thank you for providing a sample document. I also received the error "Sorry, file size is too big to save." when I tried to upload it.
I have opened bug 3480 to track this. We will update in this forum topic when there are status updates to the bug.
Posted: Tue May 19, 2009 9:58 am Post subject: Re: some first impressions
narf wrote:
Thank you for providing a sample document. I also received the error "Sorry, file size is too big to save." when I tried to upload it.
I have opened bug 3480 to track this. We will update in this forum topic when there are status updates to the bug.
The max file size was accidentally set to 300KB. We have increased it to 3MB which is will be the max file size during Preview phase. (Patrick and I remembered the max file size incorrectly as 10MB.) I am now able to upload your sample file to NeoOffice Mobile.
Are you able to upload your file to NeoOffice Mobile now?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue May 19, 2009 10:06 am Post subject: Re: some first impressions
pluby wrote:
Gust wrote:
[*]It would be nice if login & password were saved in the preference files, so you wouldn't have to enter them at every startup of NeoOffice.
I think I will need to ask to Ed if this is feasible. I know that we can store user names and passwords in your Mac OS X user keychain, but I am not sure how we can get that information to and from Apple's embedded WebKit browser.
Hmm that one I'm not sure...I think the auto-fill is something that is unique to Safari. I know when I've been testing the client, all of the cookies are saved however so once I log in the client usually leaves me logged in until we do something that resets the database on the server. Is the client automatically logging you out after certain periods of time or restarting Neo?
[*]I don't really get the concept of sharing. It seams to me that you can only share a document upon initial saving, which is a limitation anyway. I didn't manage get a doc in shared mode (whatever that may mean).
This is a good catch. Although NeoOffice Mobile allows you to rename a file, you cannot move an existing file to a different folder. Hopefully, once things settle down, Tim can take a look at that and see if that feature is feasible.
Only folders can be shared. In the NeoOffice Mobile client you create new folders. Once a folder is created it can be shared to other NeoOffice Mobile users either by user name or by email address. Individual users can be assigned Read or Read & Write privileges. Those users and their assigned privileges apply to all files in that particular folder.
However, right now it is not possible to create a new folder so I have opened bug 3482 to track this. We will post in this forum when there is an update to the bug.
Posted: Tue May 19, 2009 11:07 am Post subject: Re: some first impressions
pluby wrote:
OPENSTEP wrote:
I think I will need to ask to Ed if this is feasible. I know that we can store user names and passwords in your Mac OS X user keychain, but I am not sure how we can get that information to and from Apple's embedded WebKit browser.
Hmm that one I'm not sure...I think the auto-fill is something that is unique to Safari.
Yeah, every app has to have its own implementation of access to the Keychain (and probably the form fill code, too). I know this because AppleScript and the command-line 'security' both write endian-corrupted data to the Keychain, and while Safari can read these entries successfully, OmniWeb and other WebKit-based apps can't. (I also checked to verify that while Safari could read and fill my saved password for neomobile-test, the NeoMobile client didn't prompt me about it.)
I don't know of any open-source code for the form fill listener for WebKit (Camino and Firefox both have code for Gecko, of course ); Camino's Keychain implementation is available, but it's 'dirtied' with code to support migration from the old Keychain API and the endian consequences thereof, so writing your own code from scratch for that, if you implement password support, may be a better way to go
Since you do appear to stay logged on across NeoOffice sessions (as long as you don't manually log out, or I guess until your cookie expires), it's less of a big deal for me than I initially thought. The whole point of password managers, though, is to allow a user to choose strong passwords for individual sites and not to have to remember them, so if it is eventually possible to implement Keychain support, that would be good.
Actually, I just had another thought, though it may not be helpful, either: could you implement the login in the client in "native code" (thereby bypassing the WebKitView initially), send the login info, and then display the WebKitView, or do you still have to get the login info (cookie?) into the WebKitView?
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Posted: Tue May 19, 2009 12:59 pm Post subject: Re: some first impressions
sardisson wrote:
Actually, I just had another thought, though it may not be helpful, either: could you implement the login in the client in "native code" (thereby bypassing the WebKitView initially), send the login info, and then display the WebKitView, or do you still have to get the login info (cookie?) into the WebKitView?
This is what I had in mind. We already do the upload by invoking "load a URL" programmatically. The thing Ed and Tim need to look at is how do we structure communication with our server code to detect that our session has been logged out or expired.
However, right now it is not possible to create a new folder so I have opened bug 3482 to track this. We will post in this forum when there is an update to the bug.
--fran
Ok, you should now be able to create folders again. Are you still seeing the issue?
Posted: Tue May 26, 2009 10:42 pm Post subject: Re: some first impressions
pluby wrote:
This is a good catch. Although NeoOffice Mobile allows you to rename a file, you cannot move an existing file to a different folder. Hopefully, once things settle down, Tim can take a look at that and see if that feature is feasible.
I added a new “Move File†feature. Now a user can move files between folders. On the publish page, (in NeoOffice) select a file and in the drop down click “Move Fileâ€. This will allow more organization and allow a user to move a file in to a shared folder. Is this working for every one?
All times are GMT - 7 Hours Goto page Previous1, 2, 3Next
Page 2 of 3
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum