Re: [9fans] Omero/UI filesystem (was: Plan 9 applying to GSoC)

[sirjofri <sirjofri+ml-9fans@sirjofri.de>]

Hello you two,

yes, others in the community also pointed me towards Omero and I skimmed 
through the man page about it. I don't know much about Plan B/Octopus, 
but it seems the general idea is very similar to what I have in mind.

However (you can correct me if I'm wrong), it seems that it is tailored 
to the Plan B UI, which looks very different to the standard devdraw/rio 
way of doing UI, so I guess there's quite some work to do.

For people who are interested: I played around with the concept some time 
ago, but I wasn't good at writing filesystems back then. The solution I 
came up with was rcgui, which is not a full filesystem but just a 
connection (as a pipe) with a textual interface. 
https://git.sr.ht/~sirjofri/rcgui

In general, I believe that with solid native filesystems and solid native 
programs many applications can just be shell scripting "glue" between the 
(descriptive) UI layer and the backend filesystem. For more complex 
applications devs might want to use the native programming language to 
write this "glue" or even make it part of the native backend application.

One component-based descriptive UI filesystem would open this gate for 
both approaches and UI designers can mockup their designs very easily.

Plan 9 is often about abstracting resources as filesystems, and I believe 
UI shouldn't be an exception. Devdraw abstracts drawing already, but I 
think the common way of making/managing/controlling UI can be abstracted, 
too.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T765c829f434b0f6f-Me7af5b7e4822047d9bdf27b3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription