Re: [Tapper-pm-devel] Re: Getting this party started!

[Dag R. S. <con...@du...>]

Any File wrote:
> ----- Original Message -----
> From: "Dag Rune Sneeggen" <con...@du...>
> Subject: [Tapper-pm-docteam] Getting this party started!
> Date: Wed, 12 Oct 2005 23:48:41 +0200
> 
> 
>>As soon as I get my new domain registered, this should be replaced 
>>with something more useful and tidy.
> 
> 
> What domain name would you like?
I'll be buying nixdev.io, sort of fallen in love with the whole .io domain. It opened for public regs not long ago hehe.
Input/Output? Get it, hehe...
> 
> There is also the possibility of using the sourceforge website at http://tapper-pm.sourceforge.net/ in the meantime.
> 
> 
>>Anything we'd like to see on the soon-to-come page? Do we want a 
>>wiki or more static? Or...?
> 
> 
> I am pretty used to wiki (particularry MediaWiki), but I do not think we really need it t the moment. We can also use it but it would be not so useful. Wiki are useful when everybody on the web should be able to edit the page or when you need some feature it proviedes (e.g. to retrive previous version). Untill we are a very small group of develepors any type of system that allow as to publish (in any way) can works enought.
Perhaps I'll set up something like Plone or drupal soon-ish. Quite decent systems...
> 
> 
>>But concerning the actual tapper package manager. As for now, 
>>there's been a lot of thoughts floating around
>>in *my* head mainly.
>>Over the next few posts and discussions, we can get this "set in 
>>stone" if you'd like.
> 
> 
> Yes, it would a good thing to have something written. There is no need at all that it should be unchangeble thing (if I undestand the meaning of "set in stone"). A written document about the current situation would be very important to us to undestand what we shall do. Moreover writing down thing make them cleare than havingit in mind and the problems and the solutions that are hidden into the mind came out more easely.
Absolutely, well said.
> 
> 
>>A different point of view, is with the documentation, or design if you'd like.
>>We need to document both the actual layout and workings of the 
>>*handling* of packages locally and on servers.
>>Which formats for what? Where should what be stored? Standards and 
>>a set of rules perhaps.
> 
> 
> Yes, and before writting down the documentation we have to decide how it should work. At this point of the development we can try to use the easiest way to be implemented (untill it remains portable and do not cause any problems).
> 
> In my opinion (but I am open to hear anything about that on this) we can implement as a first step a simple program letting us open the possibility of using more complicated and powerful solutions. This would give us a quicker way to have something real on every aspect of the project to be improved. For instance we can choose an easy to implement and easy to manage database, even if not powerful and optimized and improve it or change it in the future. If thing are done in modular way (as I suppose it is the better way to implement a thing that should be portable and standard) there should not be many problems in changing things on the way while they are improoved.
Yeah, on the one hand, it would be nice if the application development moved forward very modular. So that things can be compiled
and tested from an early stage. Then again, the coders should have the freedom to do it anyway they wish.
> 
> But actually I have not very clear what should we do. I have not partecipated to your previous brainstorm, since I have just joined your project. I hope things will be more clear to me when waht extabilshed in previous discussion will be written down.
Go figure, I were basically brainstorming by myself then... :D
> 
> On the other hand what the program should do and how it is done the data exchange among the structures (server/client) should be fixed more precisely, both in order to be able to write the draft and both to be able to develop the pogram in order to respect these rules. 
> 
> 
>>On the other hand is writing (and getting approved) the 
>>Internet-Draft for the tapper protocol. Which shouldn't be *too* 
>>hard.
>>
>>So, what I suggest is getting between 2-3 C/C++ coders starting on 
>>tapd firstly, and moving on to the client at a later date?
> 
> 
> This could work, but we definetively need to extablish what everything (taht is both server and client) is expected to do before starting programming.
Well yes, that's true. But as soon as the general workings are down, the *details* in protocols etc can be adjusted along the way.
> 
> 
>>Another point, is codingstyle/guidelines. Do we need one?
> 
> 
> Weel this should be not a serious point since there are program like indent that make easy to change the style.
> 
>>While perhaps me and "AnyFile"(what's your name..?) 
>>(an...@us...)
> 
> 
> Well, let me introduce myself. My name is Andrea Fascilla. I am from Italy (and I ask you pardom in advance for the many English error I will make) and I am I boy (I just tell you this since I know that  every English belive me a girl from my name). To e-mail me you can use afa...@ma... or an...@us... . I know my skill in programming and similar are limited. I have some knowledge in C, HTML, I am (actually I was) somehow familar to RFC standards and their procedures, I can easely translate English into Italian. I have some familiarity to linux system (expecially old redHat version), I know something about linux administrations and system installation, program installation both manually (from source) and with packager manager (actully limited to rpm, which I studied at some depth some time ago)
Hi Andrea, nice to know you hehe...
> 
> 
>>could get started on the 
>>documentation.
>>First writing the I-D, then drafting out some sort of docs for 
>>other stuff that might appear.
>>
> 
> 
> Have you got any contact with the IETF folks?
> 
> Whiche is the rivelant area? The Applications Area (http://www.apps.ietf.org/)
Well, these two pages are good reads for a start; http://www.ietf.org/ID.html & http://www.ietf.org/ietf/1id-guidelines.html
Especially the part about Submissions...
Afaik, there's no need to have a specific contact within the IETF, as all I-D draft submissions are sent to a common
adress and approved/disapproved.
>  Cheers,
> AnyFile
> 


-- 

Cheers,
Dag Rune Sneeggen(ni...@du...)
---

Tapper Package Manager (http://sourceforge.net/projects/tapper-pm/) --> Do you want to miss the fun? :o