[Owncloud] ownCloud IRC Meeting 2011-09-15 Report

[Elias Probst]

On Thursday, Sept. 15th at 20:00 CEST an IRC meeting of ownCloud developers 
and contributors took place in the project's IRC channel #owncloud on the 
Freenode network.

As it turned out, the meeting was urgently needed. We discussed a lot of 
topics, some in great depth and after more than 2 hours of there was still 
quite some stuff for another 2-3 hours left. So another meeting will be 
needed.
Please add your possible dates to this Doodle: 
http://www.doodle.com/bw6wpvfzcwm5nuih

The following topics were discussed:

## Database layer
Several developers raised the need for a database framework, which is capable 
of schema migrations/versioning. Schema migrations/versioning make the users' 
and developers' lifes easier by providing a mechanism, which takes care of 
changes to the structure of the underlying database.
As ownCloud aims at a very low installation/maintenance barrier, preventing 
any troubles during updates is an important topic.

Furthermore, some suggested to use an ORM instead of raw SQL operations.
An ORM (Object Relational Mapper) provides an object oriented approach to 
databases, encapsulating single database records.
Furthermore it abstracts different database types through adaptors.

A possible issue when relying on a ORM framework is the dependency upon PHP's 
PDO support, which isn't provided by any webhoster - mostly the cheap ones 
often don't provide support for it.
As ownCloud should simply run nearly everywhere, it was decided to be 
important not to exclude such hosters.

The conclusion of the database discussion was, to aim for the integration of 
an lightweight ORM framework which also provides schema migrations support.
To make sure, hosters withouth PDO support aren't excluded, an MDB2 adaptor 
for the ORM framework to be included will be written.
This way all advantages of an ORM framework can be used, while still providing 
support for even the "low quality" hosters.
Possible candidates for an ORM to be integrated are:
Doctrine: http://www.doctrine-project.org/
RedBeanPHP: http://redbeanphp.com/


## Upload handling
The handling of file uploads probably still has some issues which aren't 
handled yet properly.
These are:
- Upload a file, when the quota/available diskspace is reached
- Upload a file, which has the same name as an existing one
- Upload a file, which is exactly the same (filename + checksum) as an 
existing one
- Upload a file and the permissions of the parent directory or an existing 
file don't allow overwriting
- Uploading a lot of files at the same time, causing blocked HTTP requests
- Drag'n'drop support for file/folder uploading
- Uploading a file to a directory, which has been deleted while the current 
view was not refreshed to reflect this deletion.

Quota/available diskspace will be handled by setting 'max_upload_size' 
dynamically and notifying the user about the reached quota.

When uploading a file with the same name as an existing one, a suffix (not 
decided yet which one) will be added to the file.

When uploading a file where the exact same copy (determined by MD5 hash and 
filename) does already exist, the already existing file is highlighted in the 
filelisting and the view scrolls to its position first when it is off-screen.

When the permissions don't allow uploading a file, a notification is shown.

When uploading a lot of files at the same time, some JavaScript should make 
sure, only one file is uploaded at a time. This could be done by building a 
temporary form and moving the files each by another to this form and 
triggering the sending of this form.

Drag'n'drop support for file/folder uploading is already planned to be 
implemented.

When uploading a file to a directory which has been deleted by other means, 
the parent directory is simply re-created. Maybe a notification could be shown 
in the webinterface.


## Authentication issues
When working in the webinterface, different things can cause a loss of the 
authentication/session like logging out in another tab, a session timeout, a 
reset of the session on the serverside etc.

A good example of how to deal with this is Twitter, where a lost session 
causes all other tabs in the browser to reload (showing the login again).

The conclusion how to deal with a lost session in the end was:
- Make sure to stop displaying any content in any tab (privacy issues)
- Show the login
- Redirect to the last active app (based on the referring URL) in each tab 
after the session is established again.

The technical side of this implementation was suggested as using JavaScript to 
provide some kind of watchdog/heartbeat which checks regularly for the 
availability of a valid session and triggers the listed actions above if 
necessary.
This would also solve the reported bug where a timeout in the image viewer 
causes unpleasant interface behaviour.



So far the topics discussed where also a final conclusion was reached.
There are still a lot of topics to be discussed in the next meeting, which are 
so far (see this Etherpad for the raw content: http://piratepad.net/CpW6il6XmJ
 ):

## Introduce some way to retrieve supported apps
The idea behind this is, to have something like GHNS in KDE, where addons can 
be easily installed directly from an application (e.g. get new wallpapers 
directly from Plasma's wallpaper dialog, get new Calligra templates, etc.)
This idea is still very vague yet and needs a lot of discussion.


## PIM Integration
- Provide an "ownCloud" ressource (just a thin wrapper around CalDAV/CardDAV) 
in Akonadi or add it to the list of supported Groupware-Servers?

## Code reuse for AJAX calls
This topic still needs some more information, but from my perspective the idea 
is probably to have e.g. one single JavaScript function which is loaded 
mandatory every time in the interface which takes further care of necessary 
actions like dealing with the authentication, showing notifications, etc.

## Log-Framework/General error handling
The current error handling in ownCloud is very poor. Only PHP's builtin 
error_log() is used which logs straightforward to STDERR (which is usually 
Apache's error_log).
There is no possibility to classify error messages in any way like making a 
difference between errors to be shown in the frontend (webinterface), 
different error levels (info .. debug) for the log output, log targets like 
deciding whether to log into an application specific logfile or just redirect 
error messages to the webserver's log etc.


So far the report - find attached the raw IRC log and a copy of the Etherpad 
in case the Etherpad is deleted/lost.


Best regards,
Elias
-------------- next part --------------
 
[19:58:52] <JanCBorchardt> yo
[19:58:57] <aqu> hello
[19:59:07] <MarcelvanLeeuwen> hey
[19:59:18] <JanCBorchardt> (I'm mobile, so the connection might drop)
[19:59:28] <aqu> ok
[19:59:40] <JanCBorchardt> so, meeting tim, who's there?
[19:59:51] <JanCBorchardt> icewind, jakobsack, bartv ?
[19:59:52] <aqu> is everyone interested in meeting are present ?
[20:01:00] <MarcelvanLeeuwen> just monitoring the channel out of interest
[20:01:13] <JanCBorchardt> nice, welcome!
[20:01:19] <MarcelvanLeeuwen> didn't know about a meeting
[20:01:24] <MarcelvanLeeuwen> thanks!
[20:02:02] <JanCBorchardt> yeah, check the mailing list (someone help me with the address)
[20:02:03] <eliasp> JanCBorchardt: I'm there
[20:02:14] <JanCBorchardt> cool
[20:02:47] <bartv> im here
[20:03:03] <JanCBorchardt> georg blizzz bartv icewind jakobsack scalability-junk meeting
[20:03:15] <JanCBorchardt> aqu do you have the agenda?
[20:03:26] <eliasp> so do we have a list of topics already? I'd also like to add some topics to discuss
[20:03:30] <aqu> i have points which needs to be discuss
[20:03:52] <eliasp> do we have an etherpad for this stuff?
[20:04:00] <aqu> no
[20:04:02] <aqu> * upload errors handling
[20:04:03] <aqu> * database problem
[20:04:07] --> raignarok (~raignarok at p5DD278D9.dip.t-dialin.net) hat #owncloud betreten
[20:04:22] <JanCBorchardt> raignarok meeting if your're interested
[20:04:43] <aqu> someone also wanted to discuss current calendar and contacts implementation progress
[20:04:49] <raignarok> I am, I hope I joined right in time?
[20:04:56] <aqu> yes
[20:04:57] <JanCBorchardt> eliasp can you sum up results of the meeting?
[20:05:02] <eliasp> I'd like to add:
[20:05:02] <eliasp> * logging framework/general error handling
[20:05:02] <eliasp> * DB migrations (if this isn't covered by "database problem")
[20:05:13] <eliasp> JanCBorchardt: like doing a protocol + a final writeup?
[20:05:35] <JanCBorchardt> ok, i'd really like icewind and jakobsack to be present. guys?
[20:05:48] <bartv> i also have an item, code reuse
[20:05:55] <eliasp> JanCBorchardt: I think icewind doesn't take part... 
[20:05:56] -*- icewind is here
[20:05:59] <JanCBorchardt> eliasp, yeah, just some sentences (I'm mobile)
[20:06:17] <eliasp> icewind: ok, nice ;)
[20:06:19] --> fosterfeld (~fosterfel at 188.111.54.34) hat #owncloud betreten
[20:06:26] <eliasp> JanCBorchardt: ok, I'll do when we finish
[20:06:34] <JanCBorchardt> thanks?
[20:06:36] <icewind> was playing minecraft....
[20:06:38] <JanCBorchardt> I mean !
[20:06:41] <eliasp> :)
[20:06:44] <JanCBorchardt> haha of course
[20:06:58] <JanCBorchardt> ok, first topic: database!
[20:07:12] <JanCBorchardt> what's up about it?
[20:07:27] --> felimwhiteley (~quassel at 46.7.101.58) hat #owncloud betreten
[20:07:31] <eliasp> is there another DB related topic besides using migrations/schema_version for DB updates?
[20:07:38] <eliasp> anyone?
[20:07:42] <icewind> I think about having a higher level database lib
[20:07:47] <zimba12> I'd like to add:
[20:07:51] --> jurica (~jurica at 77.47.2.219.dynamic.cablesurf.de) hat #owncloud betreten
[20:07:53] <bartv> i like to propose doctrine as a db layer
[20:08:16] <bartv> it has tools to do migrations between schema's
[20:08:28] <eliasp> bartv: that's nice... there'd be also Propel as an alternative
[20:08:30] <bartv> nice abstraction from sql
[20:08:36] <raignarok> i propose to have an etherpad for this meeting, with agenda & results ;) I think it workel well this way last time
[20:08:50] <eliasp> raignarok: ok, I'll open an etherpad
[20:09:09] <bartv> propel 1.? or the version based on doctrine?
[20:09:11] <eliasp> http://piratepad.net/CpW6il6XmJ
[20:09:12] <DeBot> [URL] PiratePad: CpW6il6XmJ
[20:09:32] <eliasp> bartv: oh, Propel bases on Doctrine nowadays? I've used it the last time 4 years ago
[20:10:01] <icewind> I have no experience with db layers, I'm fine with it as long as it's pretty lightweight
[20:10:06] <bartv> they are working on a version based on doctrine, not sure which propel version that would be
[20:10:13] <zimba12> as I mentioned in the list, I'd like to add:
[20:10:20] <zimba12> - akonadi integration with owncloud
[20:10:22] <eliasp> icewind: exactly: everything needs to be as lightweight as possible
[20:10:43] --> marxjohnson (~mark at host-2-102-249-152.as13285.net) hat #owncloud betreten
[20:11:04] <bartv> uing the doctrine dal will help write flexible queries
[20:11:23] <eliasp> bartv: yes, I'm a big fan of ORM layers, too... the question is: how lightweight is Doctrine?
[20:11:34] <bartv> it's pretty lightweight, mostly a wrapper around pdo
[20:11:38] <eliasp> bartv: how much dependencies does it have + how much in size?
[20:11:53] <icewind> pdo could be a problem, not al hosting provirders have it
[20:12:00] <eliasp> bartv: I'll check how much (in size) Doctrine is
[20:12:14] <eliasp> icewind: hmm, true... does Doctrine have a non-PDO fallback?
[20:12:25] <bartv> version 2.1 depends on php 5.3. is that a problem?
[20:12:33] <eliasp> bartv: no, as 5.2 is deprecated upstream
[20:12:57] <bartv> isn't pdo the default interface for 5?
[20:13:01] <icewind> I'm fine with requiring 5.3 because of something mayor like that
[20:13:12] <icewind> bartv: afaik pdo is still an optional module
[20:13:30] <eliasp> someone should verify this, before we continue discussing about it
[20:14:09] <eliasp> looks like it is integrated since 5.1 (according to Wikipedia)
[20:14:24] <eliasp> but the question is, whether it is also built into the default distribution packages
[20:14:33] <aqu> couldnt we write some wrapper for db handling and have one interface for all stuff ?
[20:14:44] <eliasp> aqu: a wrapper for a wrapper → IMHO too much
[20:15:16] <icewind> aqu: that's what oc_db does atm
[20:15:22] <aqu> wrapper for basic db func in php
[20:15:26] <bartv> debian has it as default
[20:15:29] <aqu> icewind: ok
[20:16:14] <eliasp> PDO: in Gentoo optional, not default-enforced through +pdo... how does it look like on OpenSuSE/Fedora/CentOS?
[20:16:18] <eliasp> any takers to check this?
[20:16:22] <bartv> aqu: doctrine will help you write your queries
[20:16:50] <eliasp> Doctrine takes actually the query writing away and exposes DB records as PHP objects
[20:16:50] <icewind> the main issue for pdo would be "1€ el-cheapo web hostings"
[20:17:07] <aqu> bartv: as far as i understand building queries without any sql syntax?
[20:17:10] <eliasp> icewind: yes, the question is: do they really not provide PDO? or is this just an unknown thing yet?
[20:17:16] <eliasp> aqu: correct
[20:19:17] <raignarok> I know it's not a very good approach, but: From the view of a webhoster, it doesn't make sense to deactivate PDO when they have php5, right? You can argue that for stuff like safe_mode etc, but not for something integrated in php5 by default, I think..
[20:19:25] <bartv> another way to check the question, does mysql work without pdo in 5
[20:20:30] <raignarok> it does, you can still access it via the old non-object oriented methods
[20:20:31] <eliasp> raignarok: yes, you're IMHO right... and as there might be nearly no hosters left with something that outdated as PHP 5.0 I think it's more or less safe...
[20:20:44] <eliasp> raignarok: just trying to find out a little more about PDO integration
[20:21:42] <icewind> raignarok: yes, but taking into account that it took some hosting providers about 3 years to finally use php 5.3....
[20:22:01] <-- jeffgibbs (~jeffgibbs at fw12x.mesd.k12.or.us) hat das Netzwerk verlassen (Remote host closed the connection)
[20:23:00] <eliasp> raignarok: on the other hand: do we really support something being deprecated by upstream?
[20:23:18] <eliasp> PHP 5.2 was declared deprecated by upstream I think 1 year ago
[20:23:43] <eliasp> there won't be even security updates for 5.2 anymore
[20:24:39] <eliasp> hmm, looks like some distributions (e.g. OpenSuSE, Fedora) ship PDO support as extra package
[20:24:53] <eliasp> but I don't know whether PHP-PDO is installed automatically when installing PHP
[20:24:54] <-- felimwhiteley (~quassel at 46.7.101.58) hat das Netzwerk verlassen (Read error: Connection reset by peer)
[20:25:36] <raignarok> I just looked at one of the most crappiest hosts I know ( funpic.de, free webspace) and they have pdo disabled, because they did custom changes to the php database module and didn't port them to pdo until now
[20:25:51] <eliasp> raignarok: ugh, that's actually really crappy ;)
[20:26:13] <raignarok> eliasp: you made your experiences, too? ;)
[20:26:14] <eliasp> to fasten up this decision a little: is there probably a non-PDO fallback in Doctrine?
[20:26:43] <eliasp> raignarok: no, just a statement based on yours... custom changes to the database module → sounds like ugly + dirty hacks
[20:27:06] <eliasp> http://groups.google.com/group/doctrine-dev/browse_thread/thread/3afac44dfa27b59b
[20:27:07] <DeBot> [URL] Doctrine without PDO - doctrine-dev | Google Groups
[20:27:48] <eliasp> looks like Doctrine itself relies pretty much on PDO as it completely deals with PDO objects everywhere
[20:28:13] <eliasp> while the last post there looks interesting... googling a little more for this
[20:29:29] <eliasp> back in 2008 Doctrine supported mysqli/mysql... trying to find a little more up-to-date information on it
[20:29:43] <raignarok> Well, I am not one of the owncloud coders (until now, tehe, wait for me icewind), but from a coder's view, I wouldn't want to programm with at least pdo support in php, as it suits my thoughts much better..
[20:30:35] <icewind> we always had a database abstraction layer to be indepent of mysql/sqlite/pgsql
[20:30:36] <raignarok> and I wouldn't want to do this without an ORM if i'm forced to be mysql / sqlite / whatever sql compatible and are not allowed to use MongoDB etc. ;)
[20:30:39] <eliasp> raignarok: hmm, sorry... I don't fully understand you: you mean PDO does fit or doesn't fit your thoughts?
[20:30:44] <eliasp> raignarok: ah, ok
[20:31:48] <-- dpac (~dpac at unaffiliated/dpac-/x-3408985) hat das Netzwerk verlassen (Quit: Ex-Chat)
[20:33:03] <aqu> is mdb2 installed as a default extensions in most of php installations ?
[20:33:06] <eliasp> ok, I think we need a general decision: support every f**ing crappy host or just 90% of all decent webhosts?
[20:33:17] <icewind> mdb2 is php itself, so we ship it ourself
[20:33:37] <icewind> as far as oc_db on itself, it seems pretty easy to port it to pdo since it seems to have the same syntax for prepared statements and we could still have an mdb2 fallback
[20:34:08] <eliasp> icewind: but having an MDB2 fallback would mean to keep both synchronized + a lot of code/logic duplication
[20:34:17] <aqu> and pdo is php extensions as far as i undestand ? so maybe we shouldnt introduce any special requirements ?
[20:34:32] <eliasp> aqu: correct, it is an extension, but a pretty standard nowadays
[20:34:40] <eliasp> aqu: only some really crappy webhosts don't support it
[20:35:13] <icewind> eliasp: imo we should support 99% of the webhosts (so basically not the ones that modify their database code, but try to support as most crappy hosts as possible)
[20:35:14] <aqu> but the question is how do OC benefits because of pdo requirements
[20:35:43] <icewind> for one it's probably a lot faster, mdb2 is quite messy in places
[20:35:47] <eliasp> aqu: withouth PDO means: no ORM/no DB schema support → fucking up updates for users, making developers lifes just way harder
[20:36:19] <JanCBorchardt> I mean, supporting every host (w/o root), with lowest installation barrier is why ownCloud is php
[20:36:27] <eliasp> I'm aiming especially for the DB schema support... ORM is a (pretty nice one) nice-to-have, but not that important IMHO
[20:37:12] <icewind> mdb2 has shema mangement
[20:37:30] <aqu> eliasp: so if updating will be easier, so why not write DB updater by ourself ?
[20:37:33] <eliasp> icewind: so we could continue using MDB2 and having schema management, but no ORM?
[20:37:55] <eliasp> aqu: DB updater by ourselves → way too much NIH
[20:37:59] <aqu> either way OC is now in alpha so db changes are not supported by any script whatsoever
[20:38:11] <eliasp> aqu: sure, not for now.... but we're planning for the future
[20:38:28] <icewind> orm would be nice to have, but if we need to sacrificy support for a lot of cheap hosts for that I say it's not worth it
[20:38:32] <eliasp> so: any words about the schema support of MDB2?
[20:38:43] <eliasp> icewind: correct, I agree here
[20:39:13] <aqu> 20:37 < icewind> mdb2 has shema mangement
[20:39:27] <eliasp> s/schema support/migrations support/g
[20:40:05] <eliasp> I can't find anything about native MDB2 schema migration support
[20:40:13] <eliasp> only some CakeDB related things...
[20:40:21] <icewind> it can do update shemas at least, I would copy-paste a url if my pc would let me (for some reason I can't copy-paste cross applications)
[20:40:43] <-- mollach (~davidr at host-92-4-35-228.as43234.net) hat das Netzwerk verlassen (Ping timeout: 260 seconds)
[20:41:14] <eliasp> icewind: try to drag'n'drop? :)
[20:41:27] <icewind> http://pear.php.net/manual/en/package.database.mdb2-schema.update.php
[20:41:27] <DeBot> [URL] Manual :: Updating a database against a new schema
[20:41:28] <icewind> \o/
[20:41:28] <aqu> why not paste to piratepad
[20:41:37] -*- eliasp reads this
[20:41:47] <icewind> aqu: can't copy-paste cross computer :)
[20:41:53] <aqu> oh :D
[20:42:41] <eliasp> icewind: this means schema.xml does always represent the current most up-to-date schema, while this is checked against the actually running SQL schema
[20:42:54] <eliasp> there is no schema version history in the XML itself, is that correct?
[20:43:02] <icewind> yes, that seems to be what we require for oc
[20:43:37] <eliasp> icewind: hmm, ok... I'll take a little closer look at that.. if this really works, it would be a good thing... we wouldn't have to worry about PDO/Doctrine any further and just use this
[20:43:57] <eliasp> icewind: although it might not be that advanced as full migrations support in Doctrine, it might just suffice for OC
[20:44:17] <icewind> then the question remains if we can do ORM without PDO
[20:44:39] --> daitheflu (~quassel at 2a01:e35:8a48:1800:1e6f:65ff:fe52:dd3a) hat #owncloud betreten
[20:44:47] <JanCBorchardt> ok, so do we have that as result for the first part? someone who tasks himself with investigating further?
[20:45:02] <JanCBorchardt> (we have 3 other meeting points ;)
[20:45:06] <eliasp> icewind: I actually don't think so: this would mean, there's a PHP ORM framework somewhere which implements ORM on top of mysql/mysqli/... which is very unlikely and very unlikely to be supported in the future
[20:45:30] <bartv> just asked in the doctrine channel
[20:45:36] <eliasp> ok, I'd say we settle the DB schema discussion and look forward into using MDB2's schema migration support.... I'm going to investigate a little more here
[20:46:42] <bartv> i really hope to use doctrine for oc
[20:47:03] <eliasp> bartv: I'd love this too... but it just makes OC unusable on crappy hosts
[20:47:09] <eliasp> for which whe actually aim for
[20:47:18] <bartv> true
[20:47:46] <eliasp> working with an ORM is so much more beautiful from a developer's point of view instead of raw SQL queries... but it just doesn't help when the people we aim for cannot run OC
[20:47:56] -*- klip doesn't want to interfere. Just a notice: PHPActiveRecord and RedBean ORMs have only PDO drivers as well as far as I know :/
[20:48:07] <icewind> if writing adapters for doctrine isn't to complicated it might be possible to make it work on top of oc_db
[20:48:19] --> mollach (~davidr at host-92-4-35-228.as43234.net) hat #owncloud betreten
[20:48:26] <icewind> that we way can keep all abstractions between different backends in one place
[20:48:27] <eliasp> klip: you don't interfere... that's a good information and confirms my previous suspicion
[20:49:00] <eliasp> icewind: hmm, I think writing a full adapter is probably just as much code as half of OC for now ;)
[20:49:21] <eliasp> icewind: but I'm not sure how much effort it really is... haven't checked the adapter interface yet
[20:49:33] <icewind> copy-paste can do a lot of work sometimes :)
[20:49:34] <raignarok> wordpress 7 depends on pdo by the while
[20:49:42] <eliasp> raignarok: hmm, interesting
[20:49:44] <raignarok> i mean, drupal ;)
[20:49:55] <eliasp> raignarok: ah, ok.. was wondering already about the version of WP ;)
[20:49:59] <icewind> the mdb2 sqlite3 backend was about an hour work with a ton of copy-paste from sqlite2 :)
[20:50:04] <eliasp> http://www.doctrine-project.org/api/orm/1.2/doctrine/doctrine_adapter_interface.html
[20:50:07] <DeBot> [URL] Doctrine_Adapter_Interface (Doctrine 1.2 ORM)
[20:50:15] <raignarok> checking whether other big projects can't run without pdo, too..
[20:50:48] <eliasp> implementing transaction support is just f**ed up when having to abstract it for DBs which don't support transactions natively as MySQL using MyISAM
[20:51:02] <icewind> mdb2 already does that
[20:51:12] <eliasp> icewind: oh, ok.. didn't know that... hmm
[20:51:18] <icewind> it can emulate transactions and prepared statements for crappy sql servers
[20:51:28] <eliasp> icewind: then it could be actually way easier providing an MDB2 adapter for Doctrine than I thought
[20:51:35] <bartv> doctrine can do that too
[20:51:56] <eliasp> did you others take a look at the link above (Adapter Interface)?
[20:52:06] <eliasp> looks like this is actually pretty straightforward to implement
[20:52:28] <eliasp> then we'd have to make the used Adapter configurable + have a PDO autodetection in the installer
[20:52:38] <icewind> I agree, I think we should try creating an adapter for oc_db
[20:52:50] <icewind> and have the posibility to use pdo in oc_db
[20:53:05] <eliasp> it is just too tempting having an ORM ;)
[20:53:26] <klip> RedBean ORM has nice driver interface too: http://code.google.com/p/roy-code-lib/source/browse/www.i.com/lib/RedBean/Driver.php?r=15
[20:53:27] <DeBot> [URL] Driver.php - roy-code-lib - codelib - Google Project Hosting
[20:54:19] <eliasp> hmm, and RedBean seems to be way more lightweight
[20:54:32] <eliasp> and probably doesn't even need PDO... 
[20:55:02] <icewind> so everyone agrees on trying to get doctrine (or a simular framework) on top of oc_db having all low level database abstraction done by oc_db?
[20:55:14] <aqu> looks like readbean do not needs pdo
[20:55:17] <eliasp> icewind: yes, I agree
[20:55:30] <aqu> agree
[20:55:50] --> raignarok_ (~raignarok at pD95479FD.dip.t-dialin.net) hat #owncloud betreten
[20:56:38] <icewind> good, then we can move on to the next topic
[20:56:47] <eliasp> RedBean does not work with MyISAM, but then we still have SQLite/Postgres/...
[20:56:51] <JanCBorchardt> what is it? aqu?
[20:56:56] <eliasp> icewind: ok, let's move on to the next topic
[20:57:00] <aqu> uploading error handling
[20:57:04] <eliasp> JanCBorchardt: http://redbeanphp.com
[20:57:05] <DeBot> [URL] Easy ORM for PHP. On the fly Object Relational Mapping.
[20:57:08] <aqu> errors*
[20:57:21] --> raignarok__ (~raignarok at pD9546A2C.dip.t-dialin.net) hat #owncloud betreten
[20:57:24] <JanCBorchardt> eliasp I meant the next topic ;)
[20:57:24] <icewind> the proposal was to do uploads in 2 steps right?
[20:57:29] <aqu> yes
[20:57:33] <eliasp> only 2 users in piratepad: for everyone not having joined yet: http://piratepad.net/CpW6il6XmJ
[20:57:34] <DeBot> [URL] PiratePad: CpW6il6XmJ
[20:57:39] <JanCBorchardt> but only backend-wise, right?
[20:57:47] <icewind> JanCBorchardt: yes
[20:58:04] <aqu> only exceptional cases should be decided by user
[20:58:06] <JanCBorchardt> eliasp: we should keep discussion here, pad only for summary to the mailing list
[20:58:06] <icewind> and some related gui improvements with the extra errors we can catch
[20:58:18] <aqu> so: duplicated filename should be decided
[20:58:20] <eliasp> JanCBorchardt: sure, just to make sure everyone knows about our topics ;)
[20:58:25] <JanCBorchardt> what would those errors be?
[20:58:31] <aqu> quota exeeded
[20:58:31] <-- marxjohnson (~mark at host-2-102-249-152.as13285.net) hat das Netzwerk verlassen (Remote host closed the connection)
[20:58:37] <aqu> permissions
[20:59:00] <-- raignarok (~raignarok at p5DD278D9.dip.t-dialin.net) hat das Netzwerk verlassen (Ping timeout: 260 seconds)
[20:59:01] <eliasp> icewind: regarding error presentation → postpone this to later, just outline what kind of errors we need to handle... 
[20:59:01] <icewind> I was thinking handeling quotas in the max upload size
[20:59:16] <icewind> I agree
[20:59:30] <JanCBorchardt> about quota exceeded: when you have only 20 MB left but the maxupload is 128 - we should durectly display that only 20 MB is max (for example)
[20:59:36] <raignarok__> problems with my internet connection.. sorry
[20:59:39] <-> raignarok__ heißt jetzt raignarok
[20:59:40] <JanCBorchardt> icewind haha exactly
[21:00:02] <aqu> my proposition is to gather all info about files to upload, send it to server, get some error info, then let user decide what to do
[21:00:12] <icewind> so the max upload size would be min(quota,configured upload size)
[21:00:14] <JanCBorchardt> ok so ui for errors should be similar to current undo/ diaspora: some bar on top
[21:00:22] <JanCBorchardt> no popup or shit like that
[21:00:27] <icewind> aqu: sounds like a good idea
[21:00:33] <icewind> the 2 steps
[21:00:46] <aqu> 2nd step will be uploading itself
[21:01:00] <-- raignarok_ (~raignarok at pD95479FD.dip.t-dialin.net) hat das Netzwerk verlassen (Ping timeout: 240 seconds)
[21:01:32] <eliasp> JanCBorchardt: correct, but errors in the UI is another topic for later... i got a lot to say when it comes to the Log-Framework stuff which also includes error handling in the interface... for now we should clarify what kind of errors needs to be taken care of when uploading files and talk about the presentation later
[21:01:32] <-- rom1dep (~Tamytro at 193.50.19.130) hat das Netzwerk verlassen (Read error: Connection reset by peer)
[21:01:35] <aqu> im not sure about possibility of getting filename before uploading, does anyone knows is it possible ?
[21:01:56] <icewind> it's already being done
[21:02:19] <icewind> most browsers support it (including ie)
[21:02:20] <aqu> oh right :P i found it a while ago ;) sorry
[21:02:29] <eliasp> is it possible to get the filesize before uploading a file?
[21:02:35] <aqu> yes
[21:02:42] --> rom1dep (~Tamytro at 193.50.19.130) hat #owncloud betreten
[21:02:46] <icewind> yes (supported by ie6 or 7+ iirc)
[21:02:51] <icewind> also already being done :)
[21:02:56] <eliasp> ok, then it should be also possible to pre-calculate the quota stuff before actually uploading
[21:02:57] <eliasp> oh, ok
[21:03:00] <JanCBorchardt> what about the html5 file chooser?
[21:03:12] <icewind> as in mutli-select?
[21:03:15] <icewind> or dnd?
[21:03:23] <JanCBorchardt> I only saw it in a google-io presentation
[21:03:27] <eliasp> JanCBorchardt: good point → another discussion topic → HTML5 features
[21:03:33] <JanCBorchardt> no, directly integrated in the page
[21:03:48] <aqu> but OC is already aware of multi-select
[21:03:58] <JanCBorchardt> it's on http://htmlfivewow.com I think
[21:03:59] <DeBot> [URL] HTML5 Showcase for Web Developers: The Wow and the How
[21:04:09] <JanCBorchardt> aqu it's not about multiselect
[21:04:25] <aqu> ok so ill check html5 file chooser
[21:04:40] <aqu> do you know which slide it is ?
[21:04:55] <JanCBorchardt> 50 or something, not sure
[21:05:03] <JanCBorchardt> I'm mobile atm
[21:05:03] <eliasp> do we rely on HTML5 features? so making non-HTML5 browser's unsupported? I'd actually vote for this
[21:05:11] <JanCBorchardt> yes, agree
[21:05:28] <eliasp> further votes HTML5 yes/no?
[21:05:32] <JanCBorchardt> we should support every host but use the innovation on the clients
[21:05:33] <icewind> eliasp: we only use html5 where we have fallbacks
[21:05:34] <aqu> why you
[21:05:42] <eliasp> JanCBorchardt: exactly
[21:05:48] <aqu> why you dont want to support non html5 browsers?
[21:05:59] <eliasp> icewind: ah, ok
[21:06:00] <JanCBorchardt> but also yes, we should have fallbacks
[21:07:24] <JanCBorchardt> another thing is we should probably get more into javascript so we can have smoother interface transitions, inline validation, continuous music playing etc.
[21:07:42] <JanCBorchardt> and transfer server load to the client side
[21:07:55] <JanCBorchardt> another commodity hosting point
[21:08:35] <JanCBorchardt> (sorry, I hijacked the topic)
[21:08:53] <DeBot> [rss] <rmoritz> Cannot login via webdav -   http://z.pist0s.ca/xhj
[21:09:09] <eliasp> ok, let's return to the actual topic ;)
[21:09:18] <eliasp> current topic is: Upload handling
[21:09:47] <-- georg (~georg at p5797A078.dip.t-dialin.net) hat das Netzwerk verlassen (Quit: Konversation terminated!)
[21:10:07] <-- Blizzz (~Blizzz at alfred.neversfelde.de) hat das Netzwerk verlassen (Changing host)
[21:10:07] --> Blizzz (~Blizzz at ubuntu/member/blizzz) hat #owncloud betreten
[21:10:18] <eliasp> we had several subtopics for upload handling
[21:10:32] <eliasp> 1st: user-quota... anything else to discuss here?
[21:10:55] <aqu> existing filename
[21:11:08] <icewind> I think the plan there was to limit the max upload size to the quota
[21:11:37] <JanCBorchardt> yep
[21:11:51] <aqu> let me check whats more can occure ;)
[21:11:56] <eliasp> icewind: ah, by setting the php_ini value dynamically?
[21:12:02] <JanCBorchardt> regarding existing filename: if it's the same size/date/hash, just highlight the existing file
[21:12:18] <eliasp> JanCBorchardt: agreed
[21:12:20] <-- MarcelvanLeeuwen (~chatzilla at h59057.upc-h.chello.nl) hat #owncloud verlassen
[21:12:23] <aqu> eliasp: free space on server
[21:12:30] <icewind> eliasp: yes, and the value in the html form
[21:12:37] <aqu> invalid target directory
[21:12:40] <eliasp> now we need to deal with overwriting an existing one when the uploaded file was different
[21:12:42] <JanCBorchardt> and if it's different and the revision is newer - maybe just overwrite? otherwise just upload and append "2"
[21:12:45] <icewind> aqu: is handeled the same way as quota already iirc
[21:12:52] <aqu> yes i know
[21:13:04] <aqu> but i think it will be better to unify it all
[21:13:22] <JanCBorchardt> invalid target directory? how can that happen?
[21:13:33] <JanCBorchardt> you can only upload into an existing dir
[21:13:42] <eliasp> JanCBorchardt: 2ndd connected client deletes the directory while an upload is running
[21:13:47] <aqu> you didnt refresh your windir and someone had remove this dir in other browser
[21:13:53] <eliasp> aqu: or this, agreed
[21:13:59] <JanCBorchardt> eliasp ah k
[21:14:25] <JanCBorchardt> then just upload the file in the parent dir? or recreate the directory?
[21:14:28] <aqu> authentication erro
[21:14:31] <aqu> error
[21:14:37] <JanCBorchardt> not just throw an error, solve it
[21:14:41] <eliasp> I'd vote for: re-create the directory
[21:14:52] <icewind> agree
[21:14:52] <JanCBorchardt> me too
[21:14:55] <aqu> fine
[21:14:57] <eliasp> ok, noted!
[21:14:59] <JanCBorchardt> good
[21:15:00] <aqu> 4 me
[21:15:17] <JanCBorchardt> auth error? when can that happen? when you logged out in another tab?
[21:15:36] <aqu> session timed out
[21:15:52] <JanCBorchardt> then it should reload that via js
[21:16:06] <icewind> show an ajax login form?
[21:16:13] <JanCBorchardt> nothing is more annoying than thinking you're logged in
[21:16:53] <JanCBorchardt> check twitter for example: if you log in to another account, all other opened twitter tabs reload
[21:17:06] <eliasp> JanCBorchardt: yes, that's actually quite nice
[21:17:08] <JanCBorchardt> there's no way an auth error could occur
[21:17:13] <aqu> i dont have twitter so i cant compare
[21:17:16] <eliasp> we should have something like this globally
[21:17:24] <eliasp> as similar errors might occur in a lot of other situations too
[21:17:30] <JanCBorchardt> aqu rest assured it's pretty nifty ;)
[21:17:48] <eliasp> having some JS code which makes sure the authentication state is reflected in the UI
[21:17:58] <aqu> but the question is how to authenticate via js
[21:18:06] <bartv> eliasp: yes that's what i want to talk about with code reuse
[21:18:20] <eliasp> bartv: ok, moving the auth error to the code-reuse section
[21:18:20] <icewind> anybody knows how they do it? monitoring localstorage where there is an auth value?
[21:18:29] <aqu> eliasp: you mean sending something like "hear beat msg" ?
[21:18:39] <eliasp> aqu: yes, probably something like that
[21:18:46] <eliasp> aqu: I don't know how twitter implements this
[21:19:08] <eliasp> aqu: but we might end up cloning their solution, as it is done in a way which works for millions of people
[21:19:45] <aqu> i think their solution is related with tweets streaming
[21:19:55] <JanCBorchardt> their interface is almost all js now, works very smooth
[21:19:58] <aqu> cause AFAIK tweets are done like streams
[21:20:59] <jakobsack> sorry Guys, I had another appointment
[21:21:19] <eliasp> jakobsack: some shortened backlog: http://piratepad.net/CpW6il6XmJ
[21:21:20] <DeBot> [URL] PiratePad: CpW6il6XmJ
[21:22:05] <aqu> icewind: what's Aseigo's Syncroton?
[21:22:29] <aqu> ups not icewind eliasp ;)
[21:22:32] <icewind> an ocs frontent for a git repo afaik
[21:22:58] <JanCBorchardt> so sparkleshare-like?
[21:23:09] <jekader> yep, session timeout is a bad thing! Just yesterday i "thought I were logged in" and clicked on a picture in owncloud, which resulted in a grey faded interface
[21:23:19] <jakobsack> eliasp: thx
[21:23:21] <eliasp> aqu: http://aseigo.blogspot.com/2011/01/light-up-synchrotron.html
[21:23:22] <DeBot> [URL] aseigo: light up the synchrotron
[21:23:38] <Blizzz> also sorry, was busy, i am here since 15min or so
[21:23:38] <jekader> had to press F5 to get to the login screen
[21:24:12] <aqu> so why did you put it under retrieveing supported apps ?
[21:24:32] <JanCBorchardt> icewind: is session timeout needed at all? Other web apps don't seem to have it anymore
[21:24:36] <eliasp> ehm yes, just a related topic... just using OCS for it makes more sense, sorry ;)
[21:24:54] <icewind> syncrotron might be a good adition to the existing (not fully implemented because I'm lazy) "appstore" for "official" apps
[21:25:15] <bartv> JanCBorchardt: depends on the host
[21:25:27] <JanCBorchardt> bartv what does that mean?
[21:25:32] <icewind> JanCBorchardt: I've never had it happen as long as I don't close my browser, but loging out in a different tab is still a valid case
[21:25:41] <bartv> JanCBorchardt: when de host removes the session info, you'r basicly logged out
[21:25:55] <eliasp> yes, we have to deal with the auth stuff anyways
[21:26:40] <JanCBorchardt> right, logout in a diff tab. that should then reload
[21:27:09] <eliasp> ok, it looks like we're slipping over to the auth issue everytime we discuss the upload stuff... so let's finish this now
[21:27:19] <eliasp> discussing now: authentication issue + dealing with it in the interface
[21:28:00] <eliasp> my suggestion: watching over the auth state constantly (e.g. AJAX heartbeat) using some JavaScript
[21:28:22] <eliasp> any better suggestions?
[21:28:32] <aqu> eliasp: sounds good to me
[21:28:43] <bartv> respond to error 403 codes in ajax?
[21:29:00] <icewind> eliasp: sounds fine
[21:29:23] <eliasp> bartv: I'd say: re-direct to the login-screen for everything else than a HTTP/2xx
[21:29:50] <aqu> how about 404 ?
[21:29:57] <bartv> no i don't want to end up in the login screen when i finished making a appointment
[21:29:58] <aqu> 404 its not critical error
[21:30:04] <JanCBorchardt> nonono, login screen
[21:30:18] <Blizzz> no, 404 is for non-existing pages
[21:30:18] <eliasp> JS user dialog instead?
[21:30:25] <JanCBorchardt> our goal is that no one ever sees an error screen (let alone the number 404)
[21:30:51] <aqu> but why do we handle 404 in uploading ?:D
[21:30:52] <JanCBorchardt> just the login screen
[21:30:57] <Blizzz> i pretty like the idea of an login overla<y
[21:31:07] <eliasp> hmm, not a bad idea actually
[21:31:17] <eliasp> the login overlay suggested by Blizzz
[21:31:25] <JanCBorchardt> also, is there a session timeout (based on time alone)? if so, can we get rid of it?
[21:31:40] <JanCBorchardt> wait, then the data would still be visible?
[21:32:13] <JanCBorchardt> because usecase is logout in another tab. then likely you want to log out and prob just forgot about the other tab
[21:32:19] <jekader> yes, would also love to see that - I login to goole and forums once a month, rest of the time they remember my cookies
[21:32:41] <jekader> ownClowd doesn't, even if I check the "remember" checkbox
[21:33:06] <bartv> we can store the session in the db, so we dont depend on the host session management
[21:33:08] <aqu> jekader: remember is just to fill username, not remember session
[21:33:29] <jekader> oh :)
[21:33:31] <eliasp> JanCBorchardt: correct, we have to make sure a file-index for example isn't shown anymore when the session is gone
[21:33:31] <Blizzz> JanCBorchardt: in this case it would be there... not viewable depending on how you realize it, but at least in the current source code
[21:33:54] <JanCBorchardt> remember should work like with other apps
[21:34:16] <jekader> yep, that confused me - everywhere else it remembers the session
[21:34:23] -*- icewind is grapping some popcorn :D brb
[21:34:41] <eliasp> agreed: remember should remember the session, not the username
[21:34:59] <bartv> currently the cookie is remembered till the end of the session
[21:35:12] <jekader> and my  browser is able to remember the username by itself, actually any modern browser does...
[21:35:27] <eliasp> jekader: even IE6 does ;)
[21:35:30] <aqu> ok, ill change this impl ;)
[21:36:02] <Blizzz> yeah
[21:36:08] <JanCBorchardt> aqu nice
[21:36:11] <JanCBorchardt> icewind hahaha
[21:36:27] <jakobsack> BTW, ownCloud works very well using IE10 in Windows 8 Technical Preview on the exoPC!
[21:36:34] <eliasp> hehe, nice ;)
[21:36:43] <JanCBorchardt> jakobsack you did WHAT?
[21:36:46] <JanCBorchardt> :D
[21:37:25] <jakobsack> JanCBorchardt: Yes, I did it. I was very interested in the new stuff MicroSoft introduced. Some great improvements. But this is getting too much OT
[21:37:43] <JanCBorchardt> i'll look at it
[21:37:45] <raignarok> jakobsack: I hope you wiped it immediately after that test and tested plasma active working together with owncloud? ;)
[21:37:46] <eliasp> ok, we need to get a final decision about the auth stuff
[21:37:54] <jakobsack> Ever thought about enumerating the points in the agenda. Where are we now?
[21:37:56] <eliasp> aqu will change the "remember" stuff
[21:38:25] <JanCBorchardt> so, i'd say remove session blah unless you logout in another tab. in that case put every open tab to the login screen
[21:38:43] <aqu> because first definition of remember was to remember username not session
[21:39:05] <JanCBorchardt> (that is, no logging out unless you explicitly log out)
[21:39:33] <JanCBorchardt> but only in that browser/cookie
[21:39:34] <aqu> JanCBorchardt: it is possible but require some js trick ;)
[21:40:00] <JanCBorchardt> yeah, we depend on js anyway. what does everyone else think?
[21:40:35] <aqu> ok for me
[21:40:54] --> darkh (~dark at p5DC758F7.dip.t-dialin.net) hat #owncloud betreten
[21:40:59] <jekader> oh, I also wanted to ask about file uploads via the WebUI
[21:40:59] <Blizzz> honestly i don't like when the tab automagically goes to another page
[21:41:11] <Blizzz> i prefer to login in another one and login there again
[21:41:20] <jekader> i tried to upload ~80 pictures, 3 megabytes each
[21:41:25] <eliasp> JanCBorchardt: need to clarify this again, didn't fully understand yet...
[21:41:25] <eliasp> when the auth is gone (e.g. logout in another tab, server sided timeout of session etc.), show login-page on every other tab, correct? what to do in current tab?
[21:41:34] <jekader> and some of them just didn't get uploaded
[21:41:38] <raignarok> if i understand this right, this will solve the "I close my laptop lid for standby and 4 hours later I open it up again, and I need to relogin in all wep apps"-problem? then I think it's a good proposal, too.
[21:41:50] <eliasp> jekader: we finish the auth stuff now, then return to upload issues, ok?
[21:41:57] <jekader> ok, np
[21:42:15] <JanCBorchardt> on logout, show the login screen on all tabs
[21:42:20] <JanCBorchardt> (all oc tabs)
[21:42:44] <JanCBorchardt> and end the session
[21:42:48] <eliasp> JanCBorchardt: correct... and should the login screen return me to my previous dialog then after logging in?
[21:43:30] <JanCBorchardt> eliasp ok, that's a general question - if OC should remember your currently active app, right? I am for it
[21:43:36] -*- eliasp too
[21:43:57] <eliasp> I'd actually say: not only app, but also app params (e.g. directory in files app)
[21:44:21] <icewind> basically the url (which would contain as most of the state as possible)
[21:44:41] <aqu> so additional information in db should be stored
[21:45:02] <aqu> cause its nearly impossible to store that on user side
[21:45:36] <icewind> in the sessions seems best
[21:45:39] <eliasp> aqu: right, if we don't just rely on the GET params, this would need to be stored in the DB → possibly a little too much?
[21:46:07] <eliasp> icewind: so you say we just refresh an old session of a user on the server?
[21:46:34] <icewind> yes, the session and url
[21:47:07] <eliasp> ok, so we set a very long timeout like 1 week or so for user sessions in the DB
[21:47:23] <eliasp> after this we delete old sessions as they're very unlikely to be re-used
[21:48:17] <aqu> i thought that we store this info permanently
[21:48:18] <-- fosterfeld (~fosterfel at 188.111.54.34) hat das Netzwerk verlassen (Ping timeout: 260 seconds)
[21:48:35] <aqu> because 1week vals can be stored in cookie
[21:48:44] <eliasp> aqu: yes, but at a certain point this info needs to timeout on the server too
[21:48:52] <eliasp> hmm
[21:49:00] <eliasp> maybe not... you could be right ;)
[21:49:07] <eliasp> delete a user → delete all his sessions
[21:49:47] <pprkut> if you do php sessions "natively" on the db, the deleting is done automatically from php's side
[21:49:53] <icewind> store sessions for each ip+username? I don't want my desktop session messing with the session on my laptop
[21:50:13] <icewind> hmm, ip won't cut it then
[21:50:23] <eliasp> icewind: yep
[21:50:35] <aqu> how about dynamic ip?
[21:51:09] <eliasp> hmm, this was probably a bad idea in the 1st place to try to restore the last app+params after logging in again
[21:51:25] <eliasp> I think re-using the current GET params should be enough which would just re-open the last app
[21:51:46] <eliasp> so we forget about all this "store it on the server side"
[21:51:56] <eliasp> this would just introduce way too much complications
[21:52:03] <eliasp> agreed yes/no?
[21:52:26] <aqu> agree
[21:52:26] <icewind> so store the url in the session (including get params and the part after #) in the session?
[21:52:34] <aqu> in cookie
[21:52:40] <aqu> session is to time fragile
[21:52:41] <bartv> agreed for now, after the release we can maybe do beter
[21:52:45] <icewind> k
[21:52:48] <icewind> sounds good
[21:52:52] <Blizzz> ok
[21:53:00] <eliasp> ok, writing this down
[21:53:07] <eliasp> then back to the upload things
[21:53:16] <eliasp> jekader reported some issues
[21:53:23] <eliasp> jekader: could you re-post?
[21:54:35] <aqu> i have to leave for few minutes, be back in max 0.5h
[21:54:46] <jekader> eliasp bout what?
[21:54:50] <jekader> file uploads?
[21:54:55] <eliasp> jekader: yes
[21:55:06] <jekader> Ok, so I upload files
[21:55:19] <jekader> and they start uploading all at once
[21:55:25] <eliasp> so we're near to 22:00... what about continuing this discussion during the next days?
[21:55:34] <jekader> so as a result, not all of them get to the server
[21:55:37] <eliasp> ok, let's finish jekader's report first ;)
[21:55:44] <jekader> 4 get uploaded, 4 not, and so on
[21:56:01] <jekader> I can make some users for you guys to test :)
[21:56:21] <eliasp> jekader: ok, this looks more like a bug we need to investigate a little into
[21:56:34] <jekader> the icon just keeps "spinning", but there's no upload in progress, apache gets no connections
[21:56:43] <eliasp> jekader: but not a general design question etc.
[21:56:45] <eliasp> opinions anyone?
[21:56:59] <jekader> my opinion is to upload files one-by-one
[21:57:05] <jekader> or something like that
[21:57:09] <jekader> not 80 at once
[21:57:10] <icewind> not that easy to do
[21:57:10] <eliasp> jekader: ok, I do agree here
[21:57:16] <aqu> agree
[21:57:33] <jekader> that can easily bump into the webserver connection limit
[21:57:35] <eliasp> icewind: hmm, really? can't this be controlled through JS for multi-upload forms?
[21:58:06] <aqu> js can create temporary form to upload files one by one
[21:58:35] <icewind> yes, but you would have to select files every time then
[21:58:35] <eliasp> aqu: exactly..... clone the current form outline, insert current element to upload from DOM + inject into the temporary form, then upload it
[21:58:55] <eliasp> icewind: what do you mean "select files every time then"?
[21:59:04] <icewind> afaik you cant set the file of a file input using select
[21:59:15] <JanCBorchardt> sorry, i'm out atm
[22:01:03] <icewind> using js*
[22:01:12] <eliasp> ok, I'd say that's something to investigate into... I've added it to the upload handling list for now
[22:01:48] <jekader> that's about all I noticet during the last days that annoyed me
[22:03:23] <jekader> is drag-and-drop upload implemented or planned btw?
[22:03:26] --> fosterfeld (~fosterfel at 91-65-137-67-dynip.superkabel.de) hat #owncloud betreten
[22:03:33] <icewind> planned
[22:03:35] <eliasp> ok, so back to organisational stuff.... could we continue this discussion at a later point? weekend? next week?
[22:03:41] <jekader> not a thing I personally use, but looks really user-friendly
[22:03:56] --> nnm2 (~pupu at 89-253-122-36.customers.ownit.se) hat #owncloud betreten
[22:04:23] <eliasp> please vote: continue/postpone
[22:04:51] <icewind> I'm fine with continuing now
[22:05:24] <raignarok> of-topic from the meeting, sorry, but wasn't there someone working on a plugin for something similar than deja dup, to have sync to owncloud webdav? you, JanCBochardt?
[22:06:28] <JanCBorchardt> sorry, was out since my last active post. am mobile, can someone paste the full log somewhere for later please
[22:06:44] <JanCBorchardt> nice discussion in the rideshare ;)
[22:07:17] <icewind> JanCBorchardt: wasn't much said in that time
[22:07:26] <eliasp> JanCBorchardt: I have a full backlog: http://paste.kde.org/121969
[22:07:28] <DeBot> [URL] #121969 • KDE Pastebin
[22:14:20] <eliasp> ok, so let's continue?
[22:14:33] <eliasp> or postpone here? didn't see a final voting
[22:15:00] <zimba12> PIM, CalDAV, CardDAV
[22:15:00] <zimba12> Akonadi Integration?
[22:15:03] <zimba12> still pending...
[22:15:09] <zimba12> or postponing it
[22:15:28] <eliasp> I think we could just discuss another 2-3h about the remaining topics
[22:15:35] <raignarok> i'd still have time.. but i'm possibly not the one most needed for that topic ;)
[22:15:46] <eliasp> as i have to get up early tomorrow (and other's probably too) I'd vote for postponing
[22:16:20] <eliasp> I think we actually discussed a lot of stuff yet... but we need to finalize some thoughts in another meeting
[22:16:31] <eliasp> so any suggestions when?
[22:16:54] <eliasp> what about saturday? yes/no?
[22:19:19] <icewind> fine by me (also send a mail to the list about it)
[22:19:38] <eliasp> I'd declare today's meeting as closed now, keeping the protocol for the next meeting, will write a summary + suggestion for next meeting + send it tomorrow to the list
[22:19:52] <eliasp> thanks for participating and discussing!
[22:21:09] <raignarok> thanks for managing eliasp :)
[22:21:26] <klip> nice meeting ;)
[22:21:53] <Blizzz> thanks!
[22:22:03] <jekader> thanks to everyone!
[22:23:17] <jakobsack> thanks
[22:23:41] <bartv> thanks eliasp
-------------- next part --------------
http://piratepad.net/CpW6il6XmJ

Topics:
Database:
ORM-Framework for abstraction?
Doctrine with an MDB2 Adapter?
RedBeanPHP?
Support for Schema Migrations (possibly included in ORM-Frameworks?)
Create an OC_DB adapter for doctrine (or another ORM-Framework) and have the positibility to use PDO in OC_DB for performance

Upload handling
Quotas
Available diskspace on server
Existing filename
Solution:
Exact the same file (hash/filename) does already exist:
Just highlight this file
An existing file would have been overwritten:

Ask user about overwriting ?
Target directory doesn't exist anymore
Solution: re-create the directory, when it doesn't exist anymore
Authentication error
Uploading multiple files at once
Causes trouble (webserver connection limit etc.) when uploading parallel instead of serial
Is it possible to control the upload behaviour of multiple-input form fields using JS? 

Introduce some way to retrieve supported apps
Synchrotron to provide OC apps
OCS protocol support in OC itself
Dependencies?

PIM, CalDAV, CardDAV
Akonadi Integration?

Code reuse for AJAX calls

Authentication issues
Deal with authentication state in a permanent and global way (e.g. logged out in another tab, auth timeout), update all other tabs accordingly etc.
Watch over the auth state continuously using something like a JS watchdog/heartbeat
Show the login screen in all tabs when the auth is gone
Return to the last app in each tab after logging in again by using the referring GET params

Log-Framework/General error handling
Error Targets
Application Log
 (Info → .. →  Debug)
Webserver Log
Logleves (Info → .. →  Debug)
User Interface
Admin users
Regular users

HTML5 feature usage
use HTML5 features where possible, but make sure to provide fallbacks for non HTML5 users (you even need the fallback mediaplayer if you want to play an mp3 in firefox)

TODOs:
(aqu):
change behaviour of "remember" 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20110917/a7880fe7/attachment.sig>