Re: Directories of Projects to Webize

On 31 January 2014 05:29, Tim Holborn <timothy.holborn@gmail.com> wrote:

> Something that can be easily deployed, and set-up by participants to
> network into a distributed framework for collaborative dev.  I find that
> many throughout the effort; are concerned about available resources, i'm
> sure there out there and once they figure out the benefits of this new
> 'stuff' the js work, the webzing will commence and develop.
>
> Melvin (perhaps also henry) stated three segments;
> standards<>platform<>apps - whilst this is still development focused
> (rather than broader lifecycle focus) standards and platforms exist enough
> to build apps (therefore 'webize').
>

Rather than standards<>platform<>apps, I like to think of the Linux model
of :

1 Kernel
2 Drivers
3 Apps

Now you might translate that into the web where:

1 The "kernel" are standards we use to read and write to the web -- I think
these are in pretty good shape

2 Apps are universal web based apps, that should run in any browser -- We
need more of these but it's quite a bit of work

3 Drivers are glue code to existing systems e.g. apps -- this is where I
think "webizing" can add value.  You take an existing app and with a few
tweaks make it standards compliant.  Then the whole eco system can benefit
from the functionality.

The reason I started this thread regarding directories of FLOSS projects
was really to target the "low hanging fruit".  But it's all good, the more
user friendly the web platform is, the better.  But given we have limited
resources, I thought it might be nice to target webizing some software that
would give a relatively large payoff compared with the effort required ...


>
> We've got some gurus in the group obviously; so, we've got segments of
> 'lab work' falling down to POC or 'developer kits' or so to say.  I've
> found it particularly difficult to gain traction with many external
> (geographically local) groups as the learning curve is so high, and
> time-consuming. data is out there, but it's difficult to pull together,
> which is somewhat hippo critical given these are the sorts of problems
> we're trying to solve.
>
> i agree about 'legacy systems' and i think that's also perhaps part of our
> remit.  IRC is still useful, and i've found js based (mind using node.js)
> app servers that could be webized.  alot of the work appears to need a
> means to link back to foaf, and therein; the foaf management, groups,
> address book, etc. (i.e. https://github.com/stample/react-foaf )
> important too.
>
> In-part i guess we're talking about developer accessibility. there's lots
> of people out there who know a bit of js and a bit of php; scala/java seems
> a little different, and python - well - i've heard lots and lots about it
> over the years, but still haven't been fiddling with it much...
>
> Then there's the designers who know a little CSS / HTML5 (but are magic
> with photoshop); or the game developers who can do amazing things with
> javascript like http://famo.us/  Part of our underlying assumptions mean
> it needs to be highly accessible for someone to get a rww server account -
> whether hosted, hosted for them - or build into a 'freedom server' locally
> based.  If it's not that easy for developers, then it'll be much more
> difficult to prove out to other stakeholders surrounding those developers.
>
> The other thing i believe; is that with app development will come new
> problems; which will then relate back to platform<>standards.   part of the
> challenge i envisage is ensuring apps are compatible with different
> rww-services.
>
> Which reminds me of; http://www.w3.org/People/Connolly/  "From '95 to
> '97, and this is definitely worth noting, during the struggle between
> Microsoft's Internet Explorer and Netscape Navigator<http://en.wikipedia.org/wiki/History_of_the_web_browser#Late_1990s:_Microsoft_vs_Netscape>,
> Dan chaired the working group which ensured that HTML remained an open
> standard, and for that, he was named by Interactive Magazine in '97 as one
> of the 25 unsung heroes of the web."
>
> There's a few older apps; such as https://github.com/rblin/LifeShare-4.0 (for
> example) which seemingly don't work anymore due to updated standards? few
> other issues i think, but the work - i think it's just being left...?  We
> need to create methods as a distributed team, that support growth of the
> community.
>
> reuse of RWW based work is perhaps as important (if not more important)
> than reuse of traditional LAMP systems, that are centralised in nature.
>
> just some thoughts though.
>
> comments / feedback welcome...
>
>
>
>
>
>
> On 31 Jan 2014, at 6:35 am, da <_@whats-your.name> wrote:
>
> I've been working on figuring out a better communications method - ideally
> one that uses a rww server.
>
>
> can you describe what you have in mind? eg i'm following this thread from
> within the Tabulator[0], served via a webserver inside my phone (dubbed the
> Infodaemon). presumably Kingsley if he's found this list is doing so via
> some OpenLink dataspace, Danbri perhaps via some Python that queries his
> Dydra instance. who knows..
>
> i like allowing legacy-systems to continue to exist (sometimes i just feel
> like using mutt or notmuch on the same set of files the webserver is using,
> or maybe X isn't launching since it's some RK3188 PC and the Mali400
> drivers are failing to compile for the only kernel version that the
> wifi-driver works with or whatever)
>
>
> http://mail.whats-your.name/msg/cc4/0FAA17C3-CDFB-458D-A184-B0A7D555A388@gmail.com?graph=thread&view=data
>
>
>