Re: [Userops] Userops Acid Test v0.1

[Dave Crossland]

On Sep 27, 2015 9:18 PM, "Christopher Allan Webber" <address@hidden> wrote:
>
> Dave Crossland writes:
>
> > I'd like to suggest "Self Extensibility" as a key feature of this aspect.
> >
> > I think Emacs, Blender and Firefox are huge success stories for libre
> > applications, and each owes much of its success to not only the ease of
> > scripting, but the core application design emphasising modularity: Emacs
> > has a 1% core in C, and 99% is in Lisp, making it 'self extensible.'
> > Firefox has also traditionally followed this model with XUL-based AddOns,
> > but is now self-destructing by requiring AddOns to use a limited API [1].
> > Declarative UI toolkits are important for this approach.
> >
> > Also the composability of the microservices pattern is also supportive.
> >
> > [1]:
> > http://www.zdnet.com/article/mozilla-changes-firefox-apis-developers-unhappy/
> >
> > Cheers
> > Dave
>
> This is a great way to phrase it.  I've had a hard time putting it more
> succinctly than you just did, so I updated the post and simply added a
> note about self- extensibility and linked to your email for clarity :)

Cool :)

It isn't clear to me if browser based apps, or full microservices based web applications, can be built in this way.

I've also seen in the font development community an unusual antipattern about this.... for want of a better term, "closed core."

The last Gen dominant proprietary font editor Fontlab Studio v5 peaked in 2009 and in 2011 two new proprietary mac os x based editors were launched to compete.

(The leading libre editor Fontforge was launched when the previous Gen editor Fontographer was not just peaked but fully abandoned in 2000. In 15 years this monolithic C app has grown into something like a vast monument of a long dead civilization. Worth preserving, but unmaintainable.)

The 2 editors were similar in many ways at the start, but Glyphs is a classical Objective C app with a limited api for plug-ins, and the other, RoboFont, is 100% python, using PyObjC and mit'd foundation libraries  (particularly, a declarative pythonic ui library for writing font editor cocoa UIs without XCode UI Builder, Vanilla) and a small proprietary core library "mojo" and all user facing features also MIT'd.

In the last 4 years, Glyphs developers have added a lot of features and focused on ux research based to increase productivity to make the features cohesive and enforce a particular workflow. RoboFont otoh have not done much, because they see the app as a platform and expect users to set up the features and work flows that make sense to them.

So RoboFont is a kind of closed-core model; you pay your $400 per mac seat, and there are hundreds of great features as libre licensed extensions on github, and the overall product experience is much like using a libre operating system, unlike the typical mac experience.

The result is that larger font developer orgs who employ python developers, or type designers who are also hackers, form a minority superfan customer base for RF that has peaked, and Glyphs has grown into the current Gen dominant editor.

And 4 new libre font editors have come along. 3 are web based (Metapolator, Prototypo, and Glyphr Studio) and 1 is PyQt, and is essentially a reexpression of RoboFab as it uses their libre foundation library wedded to Qt instead of Cocoa.

Glyphr is all custom js and all client side, while the other 2 use AngularJS, and prototypo has a node.js server side part. None are self extensible in the way Emacs and Robofont and the PyQt one are.

I'm most involved in Metapolator, which is today intended to follow the unhosted.org model. Previous iterations used docker containers, but today Id expect  to try sandstorm.io,  as it looks like a natural fit if mp goes down a microservices path with serverside code.

I figure that being web based, browser developer tools offer some degree of self extensibility for any js based client side app, and with some clever use of a code hosting api (such as how www.prose.io uses the github api) it might be possible to make a patch live and post it upstream, even making a pull request, directly from within the app.

But I don't know of anything that is already working this way. Does anyone here? :)

I have even less idea about how web applications with serverside components could work like this. I think containers are relevant, but I already pontificated on that last time ;)

Cheers
Dave