Re: [kDev] some quick questions on the tools plan.

["Dave Cridland [Home]" <dave@xxxxxxxxxxxx>]

On Sun, 2003-05-11 at 11:23, Mark Simpkins wrote:
> We do need some sort of repository, whether its Sourceforge or our own
> CVS. 

Or subversion, since it's easier, cross-platform, and allows better
browsing with "Web folders" et al.

> Profile:
> 
>  LDAP sounds like a good fit, being able to define organisations and
> members of those organisations. Question, these profiles and later
> user accounts are they envisaged just for the development project, or
> are they also customer and content suppliers (which of course could be
> both).
> 
> The email address mentioned later, again if this is just for the
> system development then not too many problems, but as the potential
> pool of users increases, we have more name space conflicts.

Yes, LDAP works for part of the system well - that is, a structured
directory. However, it's well known as being problematic for
unstructured contacts, whereas ACAP handles unstructured data perfectly
well.

LDAP is also known as the last dying curse of OSI. :-)

> Calendar: agree vCal style standard (does iCal use this as well?, not
> sure, also can Outlook read vCal or only its own prop. format?)

Outlook handles vCalendar in older versions, iCalendar in newer
versions. Apple's "iCal" uses iCalendar, other clients vary between
standards, most accept both.

iCalendar is an IETF standard, based on vCalendar, which came from
industry collaboration. (Those "vcf" files Daniel moans about are
actually part of the vCalendar standard, and the content of them is
matched by ACAP addressbooks, by design.)

> Forum:
> 
> Wiki is useful, but needs regular housekeeping to make sure it does
> not just fill up with comments. Some other shared space collaboration
> tools might work (for example Groove) but they can be costly tools and
> not cross platform (Groove is Win specific at the moment and I for
> example much prefer to use OS X).

I've built forum systems out of most things - databases, flat file
systems, and all sorts. By far the easiest and most scalable was using
IMAP. Let me know the feature-set, and I'll knock something together.

IMAP has the advantage that the complex part - the server - already
exists in a number of implementations, many supplying full ACL support
and other useful concepts. In addition, housekeeping tasks can be done
with pretty much any mail client.

> List management: Think we can pull together some already existing
> tools (See the Consume list at http://www.consume.net/).

Mailman? Easily extended.

> Funding:
> 
> What would be useful would be some application that could put the two
> together, those seeking and those with. To start with though a simple
> contacts page with details of requirements for funding etc. (very much
> an administration effort, pulling in the contact details for Nesta,
> arts council, local business development funds etc. what they
> can/could fund, what they wont, get links to forms etc.)

A fair amount of politcal/diplomatic/marketing effort, too, surprisingly
little in the way of programming, yes.

> Events & meetings:
> 
> Tie together LDAP and vCal systems, then also link to reports on
> meetings (Moveable Type Trackback built in, allowing people to 'blog'
> a meeting and make sure everyone knows about it. This means that we
> can use the 'blog' to minute and supply v. good reportage on a meet,
> even if it isn't a blog in the usual sense.

[iv]Calendar already handles the concept of events and meetings, so we
can largely use this. Several existing PHP based iCalendar systems
exist, I'm sure we can glue the relevant parts together into a coherent
system.

> Development:
> 
> Can we get space on a server? Is Sourceforge a good enough tool (I
> have not used SF extensively online, though we did use it internally
> at Accenture). What other tools do we need access to on the
> development server (Wiki, list management, perl, PHP)?

SF is okay, but restricted to CVS. Oh, and it seems to crash some builds
of Mozilla, I've never figured out why. :-)

Dave.