date:20120527

Re: [Owncloud] Inter-ownCloud Sharing

2012-05-27 Thread Deepak Mittal

On Sun, May 27, 2012 at 1:41 AM, Klaas Freitag  wrote:

> On 26.05.2012 13:09, Deepak Mittal wrote:
>
>> On Sat, May 26, 2012 at 4:07 PM, Frank Karlitschek> >wrote:
>>
> Hi,
>
>
>
>> You can check out my GSoC proposal at
>> http://www.google-melange.com/**gsoc/proposal/review/google/**
>> gsoc2012/dpacmittal/18002
>> .
>> This is basically how I'm implementing it although few things might change
>> during actual implementation.
>>
>
> Great proposal from a users perspective. Here are some random thoughts:
>
> - The request_file and request_file_index request: These functions provide
> a very similar functionality than the WebDAV module which is already there:
> With WebDAV you can obviously download files and get directory listings,
> however for the sharing a filter on the file listing would be needed (ie.
> which files are to share). Maybe we can combine that and not duplicate?
>

Yep, Robin told me I could use WebDAV interface for this functionality.


>
> - it might be cool to enhance the idea of what a user is in ownCloud in
> general. Currently a user is just "frank", maybe we should enhance that to
> "frank@domain". That would make a lot more possible.
>

Yes, that's the idea. It was in my mockups album.
https://picasaweb.google.com/lh/photo/vuvy62LL6e2zLvueGiDkT9MTjNZETYmyPJy0liipFm0?feat=directlink



>
> - A very special usecase of sharing is the "sharing with myself". Given
> that I can proof that frank@domainA and frank@domainB are both under my
> control the complete data can be shared between the ownClouds which in turn
> makes moving quite easy.
>
> - I think the request_user_index is not a good idea. Systems like ownCloud
> should not distribute their user lists, and (already hearing Jan objecting
> ;-) obviously not by default. I think you should know the user you want to
> share with.
>

User-index is only required for a drop-down list in which user can
search/select user to share files with. I will put an option to disable
sharing of user-index, after which user has to manually type the name is
sharing box.



>
> The API can be very useful for the client as well which we also were
> already talking about.
>

Sorry, I'm confused. Do I go ahead with my original proposal, or do I start
again with a REST API? Can someone guide me on what to do? It'd be awesome
if we could talk this over IRC or have an IRC meeting about this.



>
> Thanks,
>
> Klaas
>
> __**_
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/**listinfo/owncloud
>



-- 
Regards,
Deepak Mittal,
Twitter - @dpacmittal
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Inter-ownCloud Sharing

2012-05-27 Thread Christophe M

2012/5/26 Michael Gapczynski 

> On Saturday, May 26, 2012 07:50:45 PM Bartek Przybylski wrote:
> > > I agree this is it how it should be done. Bartek would you like to
> > > comment?
> >
> > Decision of binding owncloud instances only by admins was made for
> > save resources and restrict access to information about instance.
> > Binding between instances should allow instances to exchange
> > information like userlist, groups etc.
> > Obviously accessing sharing only by single user should also by
> > available, but i dont remember did i point it out while proposal
> > review.
> >
>
> Relying on admins to bind instances is too much restriction on who you can
> share with. I don't understand how this method saves any resources.
>
> Exchanging the list of users and groups might be nice, but I don't see why
> this is necessary. The main use case I see for sharing between instances is
> for two individuals with their own independent instances. Sharing with a
> group
> or looking through the user list on a different instance sounds really
> strange.
>
> The best possible solution is to integrate sharing with the contacts app
> and
> allow the linking of a contact to a remote ownCloud instance user. In the
> same
> fashion as Jan-Christoph pointed out with fr...@franksowncloud.org.
>
> > > I noticed in your proposal that this is focusing on files. Please note
> > > that
> > > I'm working on refactoring sharing to work with other app content.
> > >
> > > I'm starting to think that this project shouldn't be an app. I strongly
> > > believe this should be a REST API in the public namespace for apps to
> > > register specific actions with. We eventually need something so files
> can
> > > be shared, reverted to past versions, etc. from desktop and mobile
> > > clients. Apps other than just sharing should be able to talk between
> > > instances and have actions triggered by remote clients. Doing this
> > > separate from interc-ownCloud sharing will just be duplicating work.
> >
> > Project beeing api instead of app, im not sure how that was mixed up.
> > file sharing app was suppose to be example of api usage
>
> I don't understand what you mean.
>
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>



Hi !

Well I think that there is two completely different use case :

- Connect completely two OC instance to allow sharing between each users of
the two instance as if it was only one instance (the current proposal with
user list, ...). That one should be admin driven. May be used to connect
for example two enterprise  ..

- Simple user sharing between two user of different instance. Knowing the
user name and the domain of the remote user ('B'), 'A' can initiate a
sharing request with 'B' to share files with him without needing admin
permissions ('B' do you want to be my friend). You have to know the other
user. After the sharing request is accepted, 'A' and 'B' can share files.
'B' will never appear in the sharing list of 'C' on the same server as 'A'
as the share link is between 'A' and 'B'. This scenario is more for
"social" sharing.


Christophe

-- 


Un poing levé, une main tendue
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] OC4 compatibility FAIL

2012-05-27 Thread Florian Rüchel

I would prefer a warning and let the user decide. For example you could
create a "compatibility mode", basically disabling the check and any
others if it is active. Thus the user knows that certain bugs may be
because of incompatibility.
You could then provide a list of such incompatible apps so the user can
check for new, adapted versions.

Cheers,
Florian

On 26.05.2012 18:01, Frank Karlitschek wrote:
> 
> I added the check so that only apps that are compatible with the current 
> version can be installed. Most of the strange ownCloud 4 bugs reported the 
> last few days are caused because people use incompatible apps. 
> App developer have to port and test their app and mark them as compatible 
> with oC 4 before they work.
> So this is intended behavior. Similar to browser plugins for example
> 
> Frank
> 
> 
> On 26.05.2012, at 17:33, Florian Hülsmann  wrote:
> 
>> In lib/installer.php I found this check:
>>
>> $version=OC_Util::getVersion();
>>if(!isset($info['require']) or 
>> ($version[0]>$info['require'])){
>>OC_Log::write('core','App can\'t be installed because it is not 
>> compatible with this version of ownCloud',OC_Log::ERROR);
>> ...
>>
>> Which means that if the  tag content in info.xml is below the 
>> ownCloud version number, the installation fails. So in ownCloud 5 no 
>> external apps can be installed before having their  tag set to a 
>> number >= 5. Can someone please explain me the intension of this behavior? 
>> Or did I miss something?
>>
>> Thanks!
>>
>> -- 
>> Florian Hülsmann
>> 
>> http://cbix.de
>> ___
>> Owncloud mailing list
>> Owncloud@kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Inter-ownCloud Sharing

2012-05-27 Thread Nils Jansen

i agree. If n...@ownid.net wants to share something with
fr...@franksowncloud.org he needs to know his webfinger. The already
existing user/group form field for shareing files, folders, calendars &
events should be able to handle these external webfingers.

I think this would be most intuitive and least complicated on both devel
and usability side.

The "accept sharing offer" feature and notification should be
implemented globally, not only for inter owncloud sharing, no?

Looking forward to this feature very much,

Nils

Am 27.05.2012 11:26, schrieb Christophe M:
> 2012/5/26 Michael Gapczynski  >
> 
> On Saturday, May 26, 2012 07:50:45 PM Bartek Przybylski wrote:
> > > I agree this is it how it should be done. Bartek would you like to
> > > comment?
> >
> > Decision of binding owncloud instances only by admins was made for
> > save resources and restrict access to information about instance.
> > Binding between instances should allow instances to exchange
> > information like userlist, groups etc.
> > Obviously accessing sharing only by single user should also by
> > available, but i dont remember did i point it out while proposal
> > review.
> >
> 
> Relying on admins to bind instances is too much restriction on who
> you can
> share with. I don't understand how this method saves any resources.
> 
> Exchanging the list of users and groups might be nice, but I don't
> see why
> this is necessary. The main use case I see for sharing between
> instances is
> for two individuals with their own independent instances. Sharing
> with a group
> or looking through the user list on a different instance sounds really
> strange.
> 
> The best possible solution is to integrate sharing with the contacts
> app and
> allow the linking of a contact to a remote ownCloud instance user.
> In the same
> fashion as Jan-Christoph pointed out with fr...@franksowncloud.org
> .
> 
> > > I noticed in your proposal that this is focusing on files.
> Please note
> > > that
> > > I'm working on refactoring sharing to work with other app content.
> > >
> > > I'm starting to think that this project shouldn't be an app. I
> strongly
> > > believe this should be a REST API in the public namespace for
> apps to
> > > register specific actions with. We eventually need something so
> files can
> > > be shared, reverted to past versions, etc. from desktop and mobile
> > > clients. Apps other than just sharing should be able to talk between
> > > instances and have actions triggered by remote clients. Doing this
> > > separate from interc-ownCloud sharing will just be duplicating work.
> >
> > Project beeing api instead of app, im not sure how that was mixed up.
> > file sharing app was suppose to be example of api usage
> 
> I don't understand what you mean.
> 
> ___
> Owncloud mailing list
> Owncloud@kde.org 
> https://mail.kde.org/mailman/listinfo/owncloud
> 
> 
> 
> 
> Hi !
> 
> Well I think that there is two completely different use case :
> 
> - Connect completely two OC instance to allow sharing between each users
> of the two instance as if it was only one instance (the current proposal
> with user list, ...). That one should be admin driven. May be used to
> connect for example two enterprise  .. 
> 
> - Simple user sharing between two user of different instance. Knowing
> the user name and the domain of the remote user ('B'), 'A' can initiate
> a sharing request with 'B' to share files with him without needing admin
> permissions ('B' do you want to be my friend). You have to know the
> other user. After the sharing request is accepted, 'A' and 'B' can share
> files. 'B' will never appear in the sharing list of 'C' on the same
> server as 'A' as the share link is between 'A' and 'B'. This scenario is
> more for "social" sharing.
> 
> 
> Christophe
> 
> -- 
> 
> 
> Un poing levé, une main tendue
> 
> 
> 
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

-- 
Nils Jansen
Hermannstraße 48, 2. HH
12049 Berlin
tel +49 (0)30 28376529
fax +49 (0)30 8687048089
mob +49 (0)176 23553612
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] ToDo List App

2012-05-27 Thread Florian Rüchel

Is anyone working on a ToDo list app of any kind? I wanted to involve
myself and since this is a simple task I started doing it to learn the
owncloud structure.

I now have a skeleton on which I could build a nice and simple ToDo list
but I before I start to code all the fixes and such, I wanted to know if
I am doing double work or if no ToDo list app is ready to go yet?

Cheers,
javex
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] ToDo List App

2012-05-27 Thread Marcel Kühlhorn

On Sun, 2012-05-27 at 22:15 +0200, Florian Rüchel wrote:
> Is anyone working on a ToDo list app of any kind? I wanted to involve
> myself and since this is a simple task I started doing it to learn the
> owncloud structure.
> 
> I now have a skeleton on which I could build a nice and simple ToDo list
> but I before I start to code all the fixes and such, I wanted to know if
> I am doing double work or if no ToDo list app is ready to go yet?
> 
> Cheers,
> javex

I think the Tasks-App is what you're looking for.

-- 
Marcel Kühlhorn
freenode: tux93

Have a lot of fun!


signature.asc
Description: This is a digitally signed message part
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] OC4 compatibility FAIL

2012-05-27 Thread Michael Gapczynski

On Sunday, May 27, 2012 01:43:11 PM Florian Rüchel wrote:
> I would prefer a warning and let the user decide. For example you could
> create a "compatibility mode", basically disabling the check and any
> others if it is active. Thus the user knows that certain bugs may be
> because of incompatibility.
> You could then provide a list of such incompatible apps so the user can
> check for new, adapted versions.

It will most likely be changed in the future to be based on the public app api 
version. This should be finalized for ownCloud 5.


Michael
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] OC4 compatibility FAIL

2012-05-27 Thread Florian Hülsmann


Additionally upgrading apps to a newer version doesn't work.

Florian

Am 27.05.2012 23:34, schrieb Michael Gapczynski:

On Sunday, May 27, 2012 01:43:11 PM Florian Rüchel wrote:

I would prefer a warning and let the user decide. For example you could
create a "compatibility mode", basically disabling the check and any
others if it is active. Thus the user knows that certain bugs may be
because of incompatibility.
You could then provide a list of such incompatible apps so the user can
check for new, adapted versions.


It will most likely be changed in the future to be based on the public app api
version. This should be finalized for ownCloud 5.


Michael
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


--
Florian Hülsmann

http://cbix.de
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] L10N and the way to translate

2012-05-27 Thread Florian Rüchel

On the subject of how we translate string in ownCloud. I couldn't find a
lot of discussion on this subject and since I just joined in ownCloud, I
hope I can get some feedback on the reasons why certain decisions were made.

First off all, I come from Joomla and my main experience originates from
here. I have worked with other CMS in PHP but most of what I will state
is based on the Joomla practices.

The ownCloud way: As you all know, ownCloud translates by using an array
called $TRANSLATIONS and calls it via the language interfaces
t()-function. The general practice (at least in all the code I found),
was to use the english text as the key for all languages.

The Joomla way: Joomla offers a static function (which internally also
calls a language-instance) to translate strings. In Joomla the general
practice is to use a describing string like COM_CONTENT_ARTICLE_TITLE
which would then be translated to the current language. All strings are
defined in a language-ini file which is read by the PHP-parser.

Now here comes my opinion:
I have a hard with one language being the key for another. I imagine
wanting to change that string. I would have to change it in *every*
lang-file. Of course, I can accomplish that with scripts and such, but
it strikes my as no good practice.

So the first point would be: Why not use artificial strings like in
Joomla for translation. One note on the Joomla practice. Even in Joomla
I could call something like JText::_("No calendars found."); to
translate my string. Joomla would convert it to "NO_CALENDARS_FOUND"
(not sure about the full stop here), which means you only need to create
a string for the english language once you want to change that string.
Still not the best practice, but it would help keeping a system where
you save a translation file for english.
I am not sure if this would be possible in ownCloud, I have to dig
further into the code to see whether it accepts an english translation file.

The other (and minor) point is the way the strings are kept in an array:
It is only somewhat of a feeling that I can't quite describe. Having a
language file with ini-Syntax seems a lot more clean to me. You save the
work before and after the strings (like "" and ",". Instead you just put each language string in one line with
a syntax like
LANG_STRING="Translated text". The only downside here is if you want to
include the " character, you have to find a way. The joomla approach is
to put _QQ_ instead of ".

As soon as I have more room and have dug further into the core code, I
will write this style of handling the language, because I really prefer
it. I just want to hear your opinions on whether I will keep this to my
apps or there is an option to get it into the core at some time (in
which case I will integrate it into my core and provide you with the
sources).

I am looking forward to hearing your opinions and especially to learn
about the reasons behind the decision of your approach.

Cheers,
javex
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] L10N and the way to translate

2012-05-27 Thread Florian Hülsmann

Hi Florian,

The point is...

> I imagine wanting to change that string. I would have to change it in
*every*

> lang-file. Of course, I can accomplish that with scripts and such,

we wouldn't have to. AFAIK everything's done by Transifex's "tx" tool
and translation strings are managed on the web.

Cheers,

Florian (huh^^)

Am 28.05.2012 01:11, schrieb Florian Rüchel:

First off all, I come from Joomla and my main experience originates from
here. I have worked with other CMS in PHP but most of what I will state
is based on the Joomla practices.

I am looking forward to hearing your opinions and especially to learn
about the reasons behind the decision of your approach.

Cheers,
javex
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

--
Florian Hülsmann

http://cbix.de
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] L10N and the way to translate

2012-05-27 Thread Florian Rüchel


> we wouldn't have to. AFAIK everything's done by Transifex's "tx" tool
> and translation strings are managed on the web.

this would mean any app developer should also create a translation for
his project on a site like transifex? Or deal with the above mentioned
problems?

>From your statement I read that the reason for the decision was then
that Transifex does not support such artifical strings?

Cheers,
Florian

> 
> Cheers,
> 
> Florian (huh^^)
> 
> Am 28.05.2012 01:11, schrieb Florian Rüchel:
>> On the subject of how we translate string in ownCloud. I couldn't find a
>> lot of discussion on this subject and since I just joined in ownCloud, I
>> hope I can get some feedback on the reasons why certain decisions were
>> made.
>>
>> First off all, I come from Joomla and my main experience originates from
>> here. I have worked with other CMS in PHP but most of what I will state
>> is based on the Joomla practices.
>>
>> The ownCloud way: As you all know, ownCloud translates by using an array
>> called $TRANSLATIONS and calls it via the language interfaces
>> t()-function. The general practice (at least in all the code I found),
>> was to use the english text as the key for all languages.
>>
>> The Joomla way: Joomla offers a static function (which internally also
>> calls a language-instance) to translate strings. In Joomla the general
>> practice is to use a describing string like COM_CONTENT_ARTICLE_TITLE
>> which would then be translated to the current language. All strings are
>> defined in a language-ini file which is read by the PHP-parser.
>>
>> Now here comes my opinion:
>> I have a hard with one language being the key for another. I imagine
>> wanting to change that string. I would have to change it in *every*
>> lang-file. Of course, I can accomplish that with scripts and such, but
>> it strikes my as no good practice.
>>
>> So the first point would be: Why not use artificial strings like in
>> Joomla for translation. One note on the Joomla practice. Even in Joomla
>> I could call something like JText::_("No calendars found."); to
>> translate my string. Joomla would convert it to "NO_CALENDARS_FOUND"
>> (not sure about the full stop here), which means you only need to create
>> a string for the english language once you want to change that string.
>> Still not the best practice, but it would help keeping a system where
>> you save a translation file for english.
>> I am not sure if this would be possible in ownCloud, I have to dig
>> further into the code to see whether it accepts an english translation
>> file.
>>
>> The other (and minor) point is the way the strings are kept in an array:
>> It is only somewhat of a feeling that I can't quite describe. Having a
>> language file with ini-Syntax seems a lot more clean to me. You save the
>> work before and after the strings (like "> and such and save yourself the trouble of the complicated assignment via
>> "=>" and ",". Instead you just put each language string in one line with
>> a syntax like
>> LANG_STRING="Translated text". The only downside here is if you want to
>> include the " character, you have to find a way. The joomla approach is
>> to put _QQ_ instead of ".
>>
>>
>> As soon as I have more room and have dug further into the core code, I
>> will write this style of handling the language, because I really prefer
>> it. I just want to hear your opinions on whether I will keep this to my
>> apps or there is an option to get it into the core at some time (in
>> which case I will integrate it into my core and provide you with the
>> sources).
>>
>> I am looking forward to hearing your opinions and especially to learn
>> about the reasons behind the decision of your approach.
>>
>> Cheers,
>> javex
>> ___
>> Owncloud mailing list
>> Owncloud@kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
> 

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] L10N and the way to translate

2012-05-27 Thread Thomas Tanghus

On Monday 28 May 2012 01:11 Florian Rüchel wrote:
> On the subject of how we translate string in ownCloud. I couldn't find a
> lot of discussion on this subject and since I just joined in ownCloud, I
> hope I can get some feedback on the reasons why certain decisions were made.
> 
> First off all, I come from Joomla and my main experience originates from
> here. I have worked with other CMS in PHP but most of what I will state
> is based on the Joomla practices.
> 
> The ownCloud way: As you all know, ownCloud translates by using an array
> called $TRANSLATIONS and calls it via the language interfaces
> t()-function. The general practice (at least in all the code I found),
> was to use the english text as the key for all languages.
> 
> The Joomla way: Joomla offers a static function (which internally also
> calls a language-instance) to translate strings. In Joomla the general
> practice is to use a describing string like COM_CONTENT_ARTICLE_TITLE
> which would then be translated to the current language. All strings are
> defined in a language-ini file which is read by the PHP-parser.
> 
> Now here comes my opinion:
> I have a hard with one language being the key for another. I imagine
> wanting to change that string. I would have to change it in *every*
> lang-file. Of course, I can accomplish that with scripts and such, but
> it strikes my as no good practice.

I don't know how much trouble it is to update the translations, but I for one 
really prefer having natural language (English) as the key for translations. 
Even though they may change more often, I find it easier to put into context 
when having a proper string to translate, rather than and artificial 
"constant" which often tends to end up just as long anyways, and harder to get 
the meaning from.

I'm working on a proposal for a templating system which uses the current 
translation backend, but adds an easy way to use variables in the translation 
string.

At first glance I found using PHP arrays a bit unelegant (in lack of better 
words), but on seconds thought I like the KISS of it ;-)

-- 
Med venlig hilsen / Best Regards

Thomas Tanghus
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Inter-ownCloud Sharing

Re: [Owncloud] Inter-ownCloud Sharing

[Owncloud] OC4 compatibility FAIL

Re: [Owncloud] Inter-ownCloud Sharing

[Owncloud] ToDo List App

Re: [Owncloud] ToDo List App

Re: [Owncloud] OC4 compatibility FAIL

Re: [Owncloud] OC4 compatibility FAIL

[Owncloud] L10N and the way to translate

Re: [Owncloud] L10N and the way to translate

[Owncloud] L10N and the way to translate

Re: [Owncloud] L10N and the way to translate

12 matches

Site Navigation

Mail list logo

Footer information