Subject: Re: [netatalk-admins] RPM of asun's netatalk...

From: mail-atalk <[email-masked]>
Date: Wed, 11 Mar 1998 09:59:36 -0800

>I can see most people turn to Adrians version of Netatalk now. Adrian
>does a damn good work on Netatalk and it is going to be a killer-app
>for Linux!

Netatalk by itself is already a killer app, and considering its close to 
non-existing support and development by umich, I'm happy to see that 
someone picked up the baton on this project.

>Nevertheless - as far as I understand it - there is an "a sun"-Version
>and an "official" release - currently in 1.4b2 state.

A state it has been in for a VERY long time. If you consider that any 
requests and questions directed to the netatalk team at umich go 
regularly unanswered, I'm not surprised the project has been floundering.

Again, I'm very glad to see a dedicated and motivated person like Adrian 
introduce an unofficial unified release that includes many worthwile 
improvements.

Harry

---

From: Andras Kadinger <[email-masked]>
Date: Wed, 11 Mar 1998 20:39:57 +0100

Harry,

> someone picked up the baton on this project.

Please be careful not to offend the umich netatalk people. Although they
seem not to have the necessary resources dedicated to this project at
the moment, they still did a lot of work in the past, that is, created
1.4b2. It just happens so, they no longer can support netatalk as
actively as they did before - they surely have their reasons (I am
curious what those might be). Adrian's work is very important for many
of us, and I am sure we all would like to know the background, the
relationship between the two forks, as well as the planned/expected
future of the original vs. Adrian's version of netatalk - this would
clear some issues.

For I am not in the team of either Adrian or the Michigan University, I
can only ask them, please tell us more about the current dimplomatic
situation.

Sincerely,
Andras Kadinger
[email-masked]

---

From: a sun <[email-masked]>
Date: Thu, 12 Mar 1998 14:25:48 -0800 (PST)

i thought i'd clue people into my current plans for my patches to
netatalk. these plans are all somewhat contingent upon available
time. in addition, some of them are very much in the long-term view of
things.

the scoop on my part:
	1) i'll probably merge in the new solaris driver if the folks
	   at umich don't mind. i had planned on doing it by just
	   merging against 1.4b3, but i haven't received a reply on
	   when that will appear. i know there's still a problem with
	   setsockopt(SO_BROADCAST) as of the 971027 snapshot. wes? 

	2) i'll probably add in things like timeouts and finer scale
	   control of number of users, etc at some point.

	3) i'll probably add stubs to afpd to talk to a file catalogue
	   daemon for lookup and updating directories. the catalog
	   daemon will probably take a little longer to actually
           write. this should solve three problems of which i'm
	   aware:
		a) we should be able to add in persistent file id's.
		b) we should be able to tag filename lengths as short
	           (11 mac chars), medium (31 mac chars), and long
	           (255 unicode chars). this should help prepare afpd
	           for long filename support. 
	        c) directory lookups should get faster.

	4) more preparation for long filename unicode support. a spec
	   doesn't really exist yet, but i can pretty much guess some
	   of the bits that need changing. the folks at apple say that
	   a few of the functions will need continuations due to
	   afp/asp restrictions, but that should be easy enough to
	   handle. 

	5) merge in of ascii mappings so that netatalk and samba
	   interact better. i asked the folks at whistle for their
	   patches, but i haven't received them yet. this will
           probably munged with #4 to some extent.

	6) make afpd buildable without appletalk support needed. this
	   should allow many more machines to use afpd.

	7) OPI support. as far as i can, all that really needs to be
	   done is to make the printing OPI aware. that is, papd and
	   psf need to recognize OPI comments and substitute files
	   on the fly. what other uses are OPI servers used for?

-a

---

From: Peter Gutowski <[email-masked]>
Date: Fri, 13 Mar 1998 06:03:22 -0500 (EST)

> 	   on the fly. what other uses are OPI servers used for?

Including an eps file is the easiest case. To my understanding OPI servers
are a participant in completing a PostScript stream that goes to a hirez
postscript output device. There may be a challenge setting up the OPI
server to translate TIF files as well as the other less documented highrez
image formats that desktop layout programs (PageMaker, Xpress) accept as
placeable images. 

Peter Gutowski
[email-masked]

Power-Vue Graphics
Complete Electronic Prepress Service & Design
West Springfield, Massachusetts
(413) 781-5440, fax (413) 731-7650

---

From: Richard Mann <[email-masked]>
Date: Fri, 13 Mar 1998 09:43:31 -0600 (CST)

On Thu, 12 Mar 1998, a sun wrote:

> ...

	Is there a way to prevent the Macs from creating unix-unfriendly
	names? For example, my favorite nightmare example, was a folder
	full of files like this:

		chapter01Art...Saved!
		chapter02Art...Saved!
		chapter03Art...Saved?

	and I think the folder itself had a name with "..." in it. 

	Left idle on the system, the files caused no harm. But when
	a 0-level dump ran through the directory, it would usually
	lock up linux with disk errors.

	Probably nothing you can do, except user education, right?

     //\     --rich
    //  \    
   // /  \   Richard Mann -- Network Administrator
  // / /  \  P u b l i c a t i o n  S e r v i c e s,  I n c. 
  \\  / / /  Champaign, Illinois, USA 61821 (217) 398-2060 x22
   \\  / /   
    \\  /    
     \\/