Re: Re: FreePAN: an opportunity to share repositories!

On 07/01/03 13:02 +0100, [email protected] wrote:
> Hi Brian and all!
> 
> Brian Ingerson <[email protected]> wrote:
> [SNIP]
> > > I have some concern about muddying the waters as to where to look for
> > > Squeak packages - as I think Ned mentioned, SqueakMap has gained a lot of
> > > momentum and mind share lately, and if FreePAN is going to work for the
> > > Squeak community we'll have to be careful to coordinate/integrate with
> > > SqueakMap, not compete with it.
> > 
> > Definitely. It seems that FreePAN just offers SqueakMap mirroring. This
> > is something SqueakMap appears not to have. Same with Ruby and RAA. 
> 
> First of all - if I haven't already said so - I am all ears for
> coordination/integration/cooperation - that is always good. Mind though
> that SqueakMap may have an architecture (especially upcoming 1.1) that
> might make it a bit "incompatible" - I am not sure though just noting it
> for the record.
> 
> Well, in fact SqueakMap has mirroring - sort of - we just haven't set up
> any mirrors yet. :-) Ehrm. A mirror of SqueakMap is easily set up by
> simply setting up another server (identical code) and having it
> regularly update itself from the master and disabling the web UI for
> changing the model. No code to be written for this.
> 
> Setting one up is on my todo-list but so is also getting SM1.1 out of
> the door... And SM1.1 will offer more interesting replication with the
> added ability to have additional "local" content.
> 
> SM works by mirroring itself down to the client using a transaction
> model which makes it theoretically much more efficient than rsync. It
> also makes it "smartness capable" - the transactions are actually
> messages that get replayed at the client and the client modifies the
> local mirror accordingly. At that time it can "react" to the
> transactions etc.
> 
> In SM1.1 I plan to let a mirror be able to have local changes (like an
> added local package for example) that can optionally be "published" to a
> selected master higher up in the hierarchy.
> 
> This means that a person can have private packages in his/her local SM
> and a company or organisation can have companywide packages not visible
> outside the company etc.
> 
> It also means that modifications to the map can be applied locally and
> then published (compared to the current model where modifications to the
> map can only be applied on the master through the web UI).
> 
> Anyway, enough blabbering about that. :-)
> 
> > I suspect that FreePAN may offer other features too, but I'd leave it up
> > to the Language Managers as to how much they want.
> > 
> > Competition is not bad in itself. I am completely open to building
> > bridges to other facilities. But I'm also interested in offering an
> > alternative to CPAN for Perl, which in many ways has stagnated. 
> 
> The best way to collaborate here I think is by:
> 
> 1. Explaining our architectures to each other and learn good stuff.
> 2. Building a bridge from SqueakMap to FreePAN so that SqueakMap is
> mirrored into FreePAN. The other direction will be harder I think.

Agreed. 

> 
> SqueakMap is an architecture heavily focused on Squeak and should remain
> so. But if there is interest in mirroring the SM content on FreePAN then
> of course, why not! Personally I am not sure though what the advantage
> would be - don't mistake me for being negative here - I just need to get
> the advantages explained to me. :-)

I agree that FreePAN might not offer Squeak much more than a reliable
mirror infrastructure, which you could probably attain on your own.

What I do think that it might add though is exposure. Squeak seems to be
way below the radar of the masses. The nature of FreePAN is
multilingual, and I hope it becomes a common kiosk where folks can not
only shop and share their favorite language, but also learn about new
ones.

> But I don't think I want to limit the development of SM to be
> constrained by a common possibly simpler model of packages - note though
> that I haven't read up enough on FreePAN to be sure it is simpler - it's
> just a guess. SM1.1 will for example have releases of packages
> maintained as separate "records", does FreePAN have something similar?

The hallmark of FreePAN is simplicity. It's almost an exercise in
under-design. 

I see all the code packages as data. FreePAN tries to organize the data
in a very logical way. But that's about it. If it's clean and logical
people will build tools as needed.

> > BTW, I'm trying very hard not to over-architect this project. I want
> > maximum payback for effort. Especially my effort. I want it to be
> > something the community maintains.
> 
> >From my experience with developing SM and the current success (I dare
> say) of it I totally agree. SM1.0x is very simple and works mostly
> because of that AND the fact that it has a GUI inside Squeak - a very
> important feature for Squeakers. And now that it is easily bootstrapped
> from within stock Squeak it has gained even more momentum.
> 
> The community has helped out with addons, fixes and related stuff - and
> of course by publishing packages and using it. But noone (but me) has
> really dug into SM itself yet - I am waiting for that to happen still. I
> have a few volunteers lined up though, we just haven't had time yet to
> "sit down" and get cranking.
> 
> > > Assuming we can resolve that issue, I'd be willing to make sure Squeak was
> > > properly represented on FreePAN.
> > 
> > Great. Volunteered then! I'll put you down as the Squeak Content
> > Manager.
> > 
> > One thing we're doing is writing all the tools to build freepan in
> > different languages. It would be neat to see some Squeak tools. I need
> > an upload server. Seems like something you're good at.
> 
> This last paragraph got me a bit puzzled - could you elaborate? Tools?
> An upload server is trivial in Squeak - but I am not sure I know what
> you mean by it.

FreePAN is two things. 

1) There is a big static mirror of content built with symlinks, and
   metadata generated html pages. There are a bunch of little scripts
   that run to keep this up to date. Those are written in Perl and Ruby.

2) FreePAN needs a central upload server for authors to publish their
   content. This could be written in anything. Squeak might be nice :)

2a) There are also syncing sripts that pull down content from other
    archives. We do that now for RAA. Squeak might work this way too.

> > Find me on irc (see link on freepan.org) and let's discuss it further.
> 
> I will check if you are there later today. Unfortunately I am in Sweden
> so I normally don't "match" timezone-wise...

In closing, I'd say that Squeak is probably the oddest fit for FreePAN
at the moment. But everything's still young. And I am very collaborative
by nature. I think it's vital for our small languages to share
brainpower when possible, if we are going to make a dent against the
forces of silly corporate languages like Java.

But, of course, FreePAN welcomes open source Java code as well :)

Cheers, Brian