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
