NextCloud features (+ pici házvezérlés)

Azzal kapcsolatban tennék fel kérdést, hogy mi a NextCloud minimális feature-set-je a Ti szempontotokból, azaz melyek azok a szolgáltatások, amelyek miatt telepítettétek, legtöbbet használjátok, illetve ha valamelyik szolgáltatás nem lenne, akkor helyette alternatívát keresnétek? 

(A kérdés azért érdekes, legalábbis számomra, mert úgy gondolom, hogy az olyan alkalmazásokat, amelyeknél a funkciók eléggé jelentősen behatároltak, lehet hogy már nem kellene minden egyes oldalfrissítésnél szinte nulláról generálni. Természetesen számtalan szinten van cache, de ha az NC-ben külön varázsolni kell, hogy még alapbeállításnál is elfogadható sebességgel fusson, akkor ott valami koncepcionálisan nem jó.)

Ha létezne egy csak naptár/filesync szolgáltatás, ami teljesen C++ alapú lenne (plusz támogatna okosotthon funkciókat) és mindezt jelentősen gyorsabban tenné mint az NC, akkor az érdeklődésre tarhatna-e számot?
 

Hozzászólások

Nekem a legfontosabb feature a fájl megosztás volt (mily' meglepő), a személyenként megadható kvóták, illetve a közös naptár volt.

Nyilván ezeket bármelyik nagyobb szolgáltató tudja (pl. Google), de a dolog lényege pont az volt, hogy saját magunk tudjuk ezeket a dolgokat tárolni.

nalunk sokfele hozzaferes van, es hasznaljak is mindet:

- webbongeszos webes eleres barhonnan, szerkesztes onlyoffice-al

- webdav eleres, a ceges gepeken fel van mappelve nekik egy betujelre (kerberos hitelesitessel)

- sync kliens, kevesen hasznaljak, de ok nagyon (es nem csak backupra)

- plusz nalunk van meg samba eleres is, ez eleg trukkos es nem is annyira fontos, meg nem is a nextcloud csinalja, de tud rola (be van allitva hogy megengedje a kulso modositast is a fileokra, ne bizzon kizarolag a sajat cache-ben)

A második, és a negyedik az engem is érdekelne.

Webdav-nál még nem találtam rá megoldást, a Win 10-ben, hogy ne kelljen minden egyes bejelentkezéskor újra authentikálni a felcsatolt meghajtón is.

A legjobb persze az lenne, hogyha a csatolást valahogy át lehetne adni egy netlogon scriptnek, hiszen ugyanabból az AD LDAP-ból dolgozik a Nextcloud is, mint amire a windows is authentikál.

A negyediknél pedig egy samba megosztás van fel-mappelve a Nextcloud-on belül, vagy a samba közvetíti ki az egyes Nextcloud user-mappákat?

Vegyesen használjuk: én speciel NC kliensen keresztül, de van kolléga, aki inkább belép a webre. Igazából irreleváns, mert így is, úgy is.

Persze, az NC kliens szépen szinkrózik oda-vissza, ahogy illik neki (kivéve, mikor meghülyül, de ilyen szökő évente egyszer van).

filemegosztas (mast nem is hasznalunk belole), beleertve a webdav elerest is. neha meg az onlyoffice is jol jon, de nem kritikus.

gyakorlatilag dropbox/gdrive kivaltasara van...

Naptárt, névjegyeket, jegyzeteket, keypass file-t ide szinkronizálok google helyett.Szerintem poén, hogy a gpxpod-ral a lementett gps 'túra' logokat egyszerűen visszanézhetem térképen. Időnként használom a Collabora-t is online szerkesztésre.

Szerkesztve: 2021. 11. 27., szo – 16:36

Érdemes az OwnCloud Infinite Scale-t is megnézni, a CERN most vezette be: https://owncloud.com/infinite-scale/

PS: NextCloud ugye eredetileg OwnCloudból forkolt, de megtartották a hagyományos PHP alapú architektúrát, közben az OwnCloud újraírta a UI-t Vue alapokon + a backendet is Go-ban. Ez az új stack az Infinite Scale.

Miért lenne jó egy ilyen backendet C++-ban írni? Azt értem hogy csak harmada/ötöde RAM-ot igényelne meg szerencsés esetben akár 40-60%-al gyorsabb lenne, de cserébe az életed rámegy a fejlesztési időre, plusz ott a buffer overflow és társai. Hogy az NC magjában vannak koncepcionális problémák az lehetséges, de ha van ilyen akkor azt nem a nyelv okozza amiben írták. Személy szerint ha mindenáron újra akarnám írni akkor (betűrendben) Dart/Elm/Go/Spring+Kotlin közül választanék.

Én a következőképpen látom. A HA és az NC-nél is úgy tűnik, hogy jelentős megkötést és tervezési/koncepcionális sarokkövet jelent az, hogy a végső felületet mindig össze kell állítani és a webszerveren keresztül kell kiadni a böngészőnek és ugyanezen a módon fenntartani valamilyen interaktivitást. Maga az oldalgenerálás jelentős hatással van a többi részre, az oldalgenerálás köré kell felfűzni mindent, szinte minden a webböngésző alá van rendelve. 
Ettől a belső struktúra eléggé el tud bonyolódni és szétválik a szerver és a kliens oldal is: más hozzáállás/nyelv/koncepció kell a weboldal generálásához, illetve a böngészőben való interaktivitás létrehozásához. 

Én úgy közelíteném meg a problémát, hogy mindössze egyetlen egy alkalmazás lenne Ez az alkalmazás fut konzolos és grafikus üzemmódban, illetve a webböngészőben is. Ezek (mert ugye több példány fut egyszerre) kifeszítik egymás között a kommunikációs réteget, így weboldal generálás nélkül, közel real-time-ban lehetne az eseményeket átadni, s nem mellesleg valamennyire redundánssá is lehetne tenni az okosotthon vezérlést és a homecloud-ot. 

Ha egy ilyen AmoebaOS szerű rendszeren lenne megvalósítva a naptár/fileshare ... akkor szerintem jelentősen gyorsabb és kényelmesebb lehetne a használata. 

(Az életem rámegy a fejlesztési időre, ha nem lesz mögötte userbase ... :) )

 

Én úgy közelíteném meg a problémát, hogy mindössze egyetlen egy alkalmazás lenne Ez az alkalmazás fut konzolos és grafikus üzemmódban, illetve a webböngészőben is. Ezek (mert ugye több példány fut egyszerre) kifeszítik egymás között a kommunikációs réteget, így weboldal generálás nélkül, közel real-time-ban lehetne az eseményeket átadni, s nem mellesleg valamennyire redundánssá is lehetne tenni az okosotthon vezérlést és a homecloud-ot. 

Régen ezért volt sláger a Node backend mert akkor nem csak elől volt JS (react/vue) hanem hátulra is ugyanaz a JS került (aztán az electron meg az RN után mindenhova is). Kibővítve ma a Dart(+Flutter) tudja ugyanazt, pont alkalmas arra amit leírtál. Ha a fejlesztési idő viszonylatában az userbase alatt fejlesztőket értesz, akkor a C++ szerintem nem lesz eléggé vonzó ehhez a projekthez, bár ki tudja... :)